การดำเนินการที่ไม่ใช่ CRUD ในบริการ RESTful

วิธี "RESTful" ในการเพิ่มการดำเนินการที่ไม่ใช่ CRUD ไปยังบริการ RESTful คืออะไร สมมติว่าฉันมีบริการที่อนุญาตให้ CRUD เข้าถึงบันทึกเช่นนี้:

GET /api/car/123           <- Returns information for the Car object with ID 123
POST /api/car              <- Creates a new car (with properties in the request)
PUT /api/car/123           <- Updates car 123 (with properties in the request)
DELETE /api/car/123        <- Deletes car 123    
POST /api/car/123/wheel/   <- Creates a wheel and associates it to car 123

ถ้าฉันต้องการเปลี่ยนสีรถฉันก็แค่POST /api/car/123ใส่ตัวแปร POST สำหรับสีใหม่

แต่สมมติว่าฉันต้องการซื้อรถและการดำเนินการนั้นซับซ้อนกว่าการอัปเดตทรัพย์สิน "รถที่เป็นเจ้าของ" ของ "ผู้ใช้" เป็นเรื่องที่น่ายินดีหรือไม่ที่จะทำอะไรบางอย่างเช่นPOST /api/car/123/purchaseโดยที่คำว่า "ซื้อ" เป็นชื่อวิธีการเป็นหลัก หรือฉันควรใช้กริยา HTTP ที่กำหนดเองเช่นPURCHASEแทนPOST?

หรือการดำเนินการที่ไม่ใช่ CRUD อยู่นอกขอบเขตของ REST หรือไม่

ลองนึกถึงการซื้อในฐานะองค์กรธุรกิจหรือทรัพยากรในพจนานุกรม RESTful ที่กล่าวมาการซื้อเป็นการสร้างทรัพยากรใหม่ ดังนั้น:

POST /api/purchase

จะทำการสั่งซื้อใหม่ รายละเอียด (ผู้ใช้รถยนต์ ฯลฯ ) ควรอ้างอิงโดย id (หรือ URI) ภายในเนื้อหาที่ส่งไปยังที่อยู่นี้

ไม่สำคัญว่าการสั่งซื้อรถไม่ใช่แค่ INSERT ธรรมดา ๆ ในฐานข้อมูล ที่จริงแล้ว REST ไม่ได้เกี่ยวกับการเปิดเผยตารางฐานข้อมูลของคุณว่าเป็นการดำเนินการ CRUD จากมุมมองเชิงตรรกะคุณกำลังสร้างคำสั่งซื้อ (ซื้อ) แต่ฝั่งเซิร์ฟเวอร์มีอิสระที่จะทำขั้นตอนการประมวลผลได้มากเท่าที่ต้องการ

คุณยังสามารถละเมิดโปรโตคอล HTTP ได้อีก ใช้Locationส่วนหัวเพื่อส่งคืนลิงก์ไปยังคำสั่งซื้อที่สร้างขึ้นใหม่เลือกรหัสตอบกลับ HTTP อย่างระมัดระวังเพื่อแจ้งให้ผู้ใช้ทราบเกี่ยวกับปัญหา (ฝั่งเซิร์ฟเวอร์หรือไคลเอ็นต์) เป็นต้น

วิธีที่น่าสนใจอย่างที่ฉันเข้าใจก็คือคุณไม่ต้องการคำกริยา HTTP ใหม่มีคำนามที่ไหนสักแห่งที่จะหมายถึงสิ่งที่คุณต้องทำ

ซื้อรถ? ไม่อย่างนั้น

POST /api/order

สิ่งที่คุณกำลังทำจริงๆคือการสร้างคำสั่งซื้อ ดังนั้นให้เพิ่มทรัพยากรอื่นสำหรับการสั่งซื้อและโพสต์และวางไว้ที่นั่นในระหว่างกระบวนการสั่งซื้อ

คิดในแง่ของทรัพยากรมากกว่าการเรียกใช้เมธอด

ในการสรุปคำสั่งซื้อคุณอาจ POST / api / order // complete หรือคล้าย ๆ กัน

ฉันรู้สึกว่า REST API ช่วยได้หลายวิธีมากกว่าแค่การให้ความหมาย ดังนั้นจึงไม่สามารถเลือกสไตล์ RPC ได้เพียงเพราะการเรียกบางอย่างที่ดูเหมือนจะเข้าท่ากว่าในสไตล์การทำงานของ RPC ตัวอย่างคือ google maps api เพื่อค้นหาเส้นทางระหว่างสองสถานที่ มีลักษณะดังนี้: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal

พวกเขาสามารถเรียกมันว่า "findDirections" (คำกริยา) และถือว่าเป็นการดำเนินการ แต่พวกเขาสร้าง "ทิศทาง" (คำนาม) เป็นทรัพยากรและถือว่าการค้นหาทิศทางเป็นข้อความค้นหาในทรัพยากรทิศทาง (แม้ว่าภายในจะไม่มีทรัพยากรจริงที่เรียกว่าทิศทางและสามารถนำไปใช้โดยตรรกะทางธุรกิจเพื่อค้นหาทิศทางตามพารามิเตอร์)