มันเหมาะสมสำหรับทรัพยากร REST ที่จะเป็นเอกพจน์และพหูพจน์หรือไม่?


10

ฉันสงสัยว่า, มากกว่าเลย์เอาต์แบบเดิม ๆ มากกว่านี้:

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

มันจะมีประโยชน์มากกว่าไหมถ้ามีเอกพจน์และพหูพจน์เช่น:

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

ดังนั้นในการสร้างชุดผลิตภัณฑ์ที่คุณอาจทำ:

POST api/Products {data: filters} // returns api/Products/<id>

จากนั้นในการอ้างอิงคุณอาจทำ:

GET api/Products/<id> // returns array of products

ในความคิดของฉันข้อได้เปรียบหลักของการทำสิ่งต่าง ๆ ในลักษณะนี้คือมันช่วยให้แคชผลิตภัณฑ์ได้ง่าย ตัวอย่างเช่นอาจใช้เวลาหนึ่งชั่วโมงในการสะสมผลิตภัณฑ์ดังนั้นลดการโทรบนเซิร์ฟเวอร์อย่างมาก แน่นอนว่าตอนนี้ฉันเห็น แต่เพียงด้านที่ดีในการทำสิ่งนี้เท่านั้นข้อเสียคืออะไร?

คำตอบ:


6

บ่อยครั้งที่คอลเลกชันจะเป็นวิธีที่มีประโยชน์ที่สุดในการโต้ตอบกับ API ของคุณมันง่ายกว่าที่จะคิดว่าคอลเล็กชั่นหนึ่งเป็นคอลเลกชันที่มีสมาชิกเพียงคนเดียว จากนั้นหากในภายหลังคุณต้องการเปิดเผย API สำหรับการโต้ตอบกับซิงเกิ้ลมันเพียงแค่ต้องอยู่ภายใต้หน้ากากครอบคลุมแปลงซิงเกิ้ลที่ส่งผ่านไปยังคอลเลกชันกับสมาชิกนั้นจากนั้นจะใช้การใช้งาน API อื่น ๆ

ฉันเดาสิ่งที่ฉันพูดที่นี่คือถ้าคุณต้องการให้คอลเลกชันเป็นกลไกการโต้ตอบเริ่มต้นด้วยการรวบรวมเฉพาะ API และหลังจากระบบเสร็จสมบูรณ์ API อื่น ๆ ก็คือการเพิ่มประสิทธิภาพการประสานที่เรียบง่ายที่เลเยอร์อินเทอร์เฟซ คุณพบว่ามีประโยชน์อย่างยิ่ง อย่างไรก็ตามคุณอาจพบว่ามีประโยชน์น้อยมากที่จะใช้ YAGNI และใช้อินเทอร์เฟซการรวบรวมสำหรับคนโสดที่คุณต้องการ


ในขณะที่ฉันเห็นด้วยกับความรู้สึกของคุณโดยสมมติว่าเราใช้ตัวอย่างด้านบนเนื่องจาก POST api / ผลิตภัณฑ์จะใช้สำหรับการส่งผ่านพารามิเตอร์ตัวกรองการรวบรวมและไม่ใช่ข้อมูลสำหรับการสร้างผลิตภัณฑ์ใหม่สิ่งที่จะเป็นวิธีที่สมเหตุสมผลในการสร้างผลิตภัณฑ์ใหม่ โดยไม่ต้อง API / ผลิตภัณฑ์?
Eva

@Evan เหตุใดจึงไม่สามารถโพสต์ไปที่ api / ผลิตภัณฑ์แทรกหลาย ๆ ผลิตภัณฑ์ (หรือคอลเล็กชันของหนึ่งรายการ) นั่นดูเหมือนจะสมเหตุสมผลที่สุดสำหรับฉัน อาจโพสต์ผลิตภัณฑ์ / ตัวกรองเพื่อสร้างตัวกรองหรือรับหากพวกเขากำลังเรียกคืนและไม่ใช่งานที่สร้างสรรค์
Jimmy Hoffa

ขอบคุณสำหรับความประณีตจิมมี่ เหตุผลที่ฉันไม่เห็นด้วยวิธีนี้คือฉันกำลังพิจารณาตัวอย่างด้านบนคอลเลกชันเป็นทรัพยากรที่ระบุในและของตัวเอง ในส่วนหลัง api / ผลิตภัณฑ์อาจเป็น "ผลิตภัณฑ์" และ api / ผลิตภัณฑ์ดังนั้น "ProductCollection" อย่างไรก็ตามหลังจากการพิจารณาบางอย่างฉันคิดว่ามันอาจจะดีกว่าที่จะเป็นนามธรรมที่อยู่ห่างจาก API ตามที่คุณแนะนำ ... ตอนนี้กับคำถามจริงคุณขับรถออกจากรถบรรทุกหยุดระหว่างทางไปประเทศไทยหรือไม่ ในการบูทรถยนต์หรือไม่?
Eva

@ ฉันจะให้คำแนะนำสองอย่างแก่คุณ: นกนางนวล
จิมมี่ฮอฟฟา

1

ข้อเสียคือโปรแกรมเรียกใช้ยังต้องสร้างชื่อทรัพยากรซึ่งอาจเป็นเรื่องยากสำหรับภาษาไคลเอนต์เหล่านั้นที่ไม่มีกลไกการแยกส่วนในตัว หากคุณปล่อยให้เป็นเอกเทศผู้โทรสามารถสร้างรหัสอัตโนมัติสำหรับไลบรารีไคลเอ็นต์ของเขาหรือเธอได้ง่ายขึ้น

หากคุณต้องการลดสิ่งนี้คุณสามารถสร้าง SDK สำหรับบริการ REST ของคุณได้ด้วยตัวเอง หรือคุณสามารถให้ความเห็นและจัดการกับข้อร้องเรียน :)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.