REST API แนวปฏิบัติที่ดีที่สุด: วิธียอมรับรายการค่าพารามิเตอร์เป็นอินพุต [ปิด]

409

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้

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

ปิดให้บริการใน2 ปีที่ผ่านมา

เรากำลังเปิดตัว REST API ใหม่และฉันต้องการให้ชุมชนป้อนข้อมูลเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับวิธีที่เราควรจัดรูปแบบพารามิเตอร์อินพุต:

ตอนนี้ API ของเรานั้นมี JSON เป็นศูนย์กลางมาก (จะส่งคืน JSON เท่านั้น) การพิจารณาว่าเราต้องการ / จำเป็นต้องส่งคืน XML หรือไม่นั้นเป็นปัญหาแยกต่างหาก

เนื่องจากเอาท์พุท API ของเราคือ JSON centric เราได้ลงเส้นทางที่อินพุตของเราเป็น JSON centric เล็กน้อยและฉันคิดว่ามันอาจจะสะดวกสำหรับบางคน แต่แปลกโดยทั่วไป

ตัวอย่างเช่นเพื่อรับรายละเอียดผลิตภัณฑ์บางอย่างที่สามารถดึงผลิตภัณฑ์หลายรายการพร้อมกันในขณะนี้เรามี:

http://our.api.com/Product?id=["101404","7267261"]

เราควรทำให้สิ่งนี้ง่ายขึ้นเช่น:

http://our.api.com/Product?id=101404,7267261

หรือมีการป้อนข้อมูล JSON มีประโยชน์หรือไม่ ปวดมากขึ้นไหม?

เราอาจต้องการยอมรับทั้งสองสไตล์ แต่ความยืดหยุ่นนั้นจริงทำให้เกิดความสับสนมากขึ้นและปวดหัว (การบำรุงรักษาเอกสารประกอบ ฯลฯ )?

กรณีที่ซับซ้อนมากขึ้นคือเมื่อเราต้องการเสนออินพุตที่ซับซ้อนมากขึ้น ตัวอย่างเช่นหากเราต้องการอนุญาตให้ใช้ตัวกรองหลายตัวในการค้นหา:

http://our.api.com/Search?term=pumas&filters={"productType":["Clothing","Bags"],"color":["Black","Red"]}

เราไม่ต้องการใส่ประเภทตัวกรอง (เช่นประเภทผลิตภัณฑ์และสี) เป็นชื่อคำขอเช่นนี้:

http://our.api.com/Search?term=pumas&productType=["Clothing","Bags"]&color=["Black","Red"]

เพราะเราต้องการจัดกลุ่มตัวกรองทั้งหมดเข้าด้วยกัน

ในท้ายที่สุดสิ่งนี้สำคัญจริงๆหรือ อาจเป็นไปได้ว่ามี JSON มากมายออกมาที่นั่นว่าประเภทอินพุตไม่สำคัญมากนัก

ฉันรู้ว่าไคลเอนต์ JavaScript ของเราที่โทร AJAX ไปยัง API อาจชื่นชมอินพุต JSON เพื่อทำให้ชีวิตง่ายขึ้น

api rest

— whatupwilly
แหล่งที่มา

341

ย้อนกลับ

ก่อนอื่น REST จะอธิบาย URI ว่าเป็นรหัสเฉพาะที่เป็นสากล มีคนจำนวนมากเกินไปที่จะเข้าใจถึงโครงสร้างของ URIs และ URI ใดที่ "สงบ" มากกว่าคนอื่น ๆ อาร์กิวเมนต์นี้เป็นเรื่องที่น่าหัวเราะเหมือนการตั้งชื่อใครบางคนว่า "บ็อบ" นั้นดีกว่าการตั้งชื่อเขาว่า "โจ" - ทั้งสองชื่อได้งานของ "การระบุคน" ที่ทำได้ URI ไม่มีอะไรมากไปกว่าชื่อที่ ไม่เหมือนใครในระดับสากล

ดังนั้นในสายตาของ REST จึงโต้เถียงกันว่า?id=["101404","7267261"]มีความสงบมากกว่า?id=101404,7267261หรือ\Product\101404,7267261ค่อนข้างไร้ประโยชน์

ตอนนี้ต้องบอกว่าหลาย ๆ ครั้งที่การสร้าง URIs สามารถใช้เป็นตัวบ่งชี้ที่ดีสำหรับปัญหาอื่น ๆ ในบริการ RESTful มีค่าสถานะสีแดงสองสามค่าใน URIs ของคุณและคำถามโดยทั่วไป

ข้อเสนอแนะ

หลาย URI สำหรับทรัพยากรเดียวกันและ Content-Location

เราอาจต้องการยอมรับทั้งสองสไตล์ แต่ความยืดหยุ่นนั้นจริงทำให้เกิดความสับสนมากขึ้นและปวดหัว (การบำรุงรักษาเอกสารประกอบ ฯลฯ )?

URI ระบุทรัพยากร ทรัพยากรที่แต่ละคนควรมีหนึ่ง URI ที่ยอมรับ นี่ไม่ได้หมายความว่าคุณไม่สามารถมี URIs สองตัวชี้ไปที่ทรัพยากรเดียวกันแต่มีวิธีกำหนดที่ดีในการดำเนินการ หากคุณตัดสินใจที่จะใช้ทั้งรูปแบบ JSON และรายการตามรูปแบบ (หรือรูปแบบอื่น ๆ ) คุณต้องตัดสินใจว่ารูปแบบใดเป็นรูปแบบURI ซึ่งเป็นที่ยอมรับหลัก การตอบกลับทั้งหมดไปยัง URIs อื่น ๆ ที่ชี้ไปที่ "ทรัพยากร" เดียวกันควรรวมContent-Locationส่วนหัวไว้ด้วย

การติดกับการเปรียบเทียบชื่อการมี URI หลายรายการก็เหมือนกับมีชื่อเล่นให้ผู้คน เป็นที่ยอมรับได้อย่างสมบูรณ์แบบและบ่อยครั้งค่อนข้างมีประโยชน์ แต่ถ้าฉันใช้ชื่อเล่นฉันยังคงต้องการทราบชื่อเต็มของพวกเขา - วิธี "ทางการ" ในการอ้างถึงบุคคลนั้น ด้วยวิธีนี้เมื่อมีคนพูดถึงใครบางคนด้วยชื่อเต็มของพวกเขา "Nichloas Telsa" ฉันรู้ว่าพวกเขากำลังพูดถึงบุคคลเดียวกันกับที่ฉันเรียกว่า "Nick"
"ค้นหา" ใน URI ของคุณ

กรณีที่ซับซ้อนมากขึ้นคือเมื่อเราต้องการเสนออินพุตที่ซับซ้อนมากขึ้น ตัวอย่างเช่นหากเราต้องการอนุญาตให้ใช้ตัวกรองหลายตัวในการค้นหา ...

กฎทั่วไปของหัวแม่มือของฉันคือถ้า URI ของคุณมีคำกริยามันอาจเป็นข้อบ่งชี้ว่ามีบางอย่างปิดอยู่ URI ระบุทรัพยากร แต่ไม่ควรระบุสิ่งที่เราทำกับทรัพยากรนั้น นั่นคืองานของ HTTP หรือในแง่ที่สงบ "ชุดอินเตอร์เฟส" ของเรา

ในการเอาชนะชื่อที่คล้ายคลึงกันการใช้คำกริยาใน URI เปรียบเสมือนการเปลี่ยนชื่อของใครบางคนเมื่อคุณต้องการโต้ตอบกับพวกเขา ถ้าฉันมีปฏิสัมพันธ์กับบ๊อบชื่อของบ๊อบจะไม่กลายเป็น "BobHi" เมื่อฉันอยากจะทักทายเขา ในทำนองเดียวกันเมื่อเราต้องการ "ค้นหา" ผลิตภัณฑ์โครงสร้าง URI ของเราไม่ควรเปลี่ยนจาก "/ Product / ... " เป็น "/ Search / ... "

ตอบคำถามเริ่มต้นของคุณ

เกี่ยวกับ["101404","7267261"]vs 101404,7267261: คำแนะนำของฉันที่นี่คือการหลีกเลี่ยงไวยากรณ์ JSON เพื่อประโยชน์ของความเรียบง่าย (เช่นไม่ต้องการให้ผู้ใช้ของคุณทำการเข้ารหัส URL เมื่อคุณไม่จำเป็นต้อง) มันจะทำให้ API ของคุณใช้งานได้ง่ายขึ้น ยิ่งไปกว่านั้นตามที่คนอื่น ๆ แนะนำให้ใช้application/x-www-form-urlencodedรูปแบบมาตรฐานเนื่องจากอาจคุ้นเคยกับผู้ใช้ปลายทางของคุณมากที่สุด (เช่น?id[]=101404&id[]=7267261) มันอาจจะไม่ "สวย" แต่ยูริสสวยไม่จำเป็นต้องหมายถึงยูริที่ใช้งานได้ อย่างไรก็ตามเพื่อย้ำจุดเริ่มต้นของฉันแม้ว่าท้ายที่สุดเมื่อพูดถึง REST มันไม่สำคัญ อย่าอยู่กับมันหนักเกินไป
ตัวอย่าง URI การค้นหาที่ซับซ้อนของคุณสามารถแก้ไขได้ในลักษณะเดียวกับตัวอย่างผลิตภัณฑ์ของคุณ ฉันขอแนะนำให้ไปที่application/x-www-form-urlencodedรูปแบบอีกครั้งเนื่องจากเป็นมาตรฐานที่หลายคนคุ้นเคย นอกจากนี้ฉันขอแนะนำให้ผสานทั้งสอง

URI ของคุณ ...

/Search?term=pumas&filters={"productType":["Clothing","Bags"],"color":["Black","Red"]}

URI ของคุณหลังจากถูกเข้ารหัส URI ...

/Search?term=pumas&filters=%7B%22productType%22%3A%5B%22Clothing%22%2C%22Bags%22%5D%2C%22color%22%3A%5B%22Black%22%2C%22Red%22%5D%7D

สามารถแปลงเป็น ...

/Product?term=pumas&productType[]=Clothing&productType[]=Bags&color[]=Black&color[]=Red

นอกเหนือจากการหลีกเลี่ยงความต้องการของการเข้ารหัส URL และทำให้สิ่งต่าง ๆ ดูเป็นมาตรฐานมากขึ้นตอนนี้มันก็ทำให้ homogenize API เล็กน้อย ผู้ใช้รู้ว่าหากพวกเขาต้องการเรียกคืนผลิตภัณฑ์หรือรายการผลิตภัณฑ์ (ทั้งคู่ถือว่าเป็น "ทรัพยากร" เดียวในเงื่อนไข RESTful) พวกเขาสนใจ/Product/...URIs

— nategood
แหล่งที่มา

67

ต้องการติดตามและทราบว่า[]ไวยากรณ์ไม่ได้รับการสนับสนุนเสมอ (และแม้ว่าจะเป็นเรื่องปกติก็ตามแม้อาจเป็นการละเมิดข้อกำหนด URI) เซิร์ฟเวอร์ HTTP และภาษาการเขียนโปรแกรมบางอย่างต้องการเพียงแค่ทำซ้ำชื่อ (เช่นproductType=value1&productType=value2)

— nategood

1

คำถามเริ่มต้นด้วยข้อความค้นหานี้ .. "/ Search? term = pumas & filters = {" productType ": [" เสื้อผ้า "," กระเป๋า "]," สี ": [" ดำ "," สีแดง "]}" แปลเป็น .. . (productType == เสื้อผ้า || productType == กระเป๋า) && (สี == || color == สีแดง) แต่วิธีแก้ไขปัญหาของคุณ: / ผลิตภัณฑ์? term = pumas & productType [] = เสื้อผ้า & productType [] = กระเป๋า & color [] = สีดำและสี [] = สีแดงดูเหมือนว่าจะแปลเป็น ... อย่างใดอย่างหนึ่ง (productType == เสื้อผ้า || productType == กระเป๋า || สี == ดำ || สี == สีแดง) หรือทั้งสอง (productType == เสื้อผ้า && productType == กระเป๋า && สี == black && color == red) ซึ่งดูเหมือนว่าจะแตกต่างจากฉันเล็กน้อย หรือฉันเข้าใจผิด?

— โทมัสเฉิง

2

สิ่งที่เกี่ยวกับอินพุตในคำขอโพสต์ ฉันต้องการทราบว่าเรากำลังอัปเดตทรัพยากรหรือไม่หากเป็นเช่นนั้นมันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะส่งเคียวรี / ตัวกรองและข้อมูลในร่างกายในรูปแบบมาตรฐาน สำหรับเช่น ถ้าฉันต้องการเปลี่ยนข้อมูลที่เกี่ยวข้องกับผู้ใช้โดยใช้ api /user/และในเนื้อหาฉันจะส่ง{ q:{}, d: {} }ด้วยqแบบสอบถามโดยผู้ใช้จะถูกสอบถามในฐานข้อมูลและdเป็นข้อมูลที่ถูกแก้ไข

— โมเลกุล

1

คุณจะทำอย่างไรเมื่อรายการอาจมีขนาดใหญ่มาก? URI นั้นมีความยาว จำกัด ขึ้นอยู่กับเบราว์เซอร์ ฉันมักจะเปลี่ยนไปใช้คำขอโพสต์และส่งรายการในเนื้อหา มีคำแนะนำอะไรบ้าง?

— ทรอย Cosentino

4

มันจะต้องมีขนาดใหญ่มาก (ดูstackoverflow.com/questions/417142/ ...... ) แต่ใช่ในกรณีที่รุนแรงที่สุดคุณอาจต้องใช้เนื้อหาของคำขอ การโพสต์ข้อความค้นหาข้อมูลเป็นหนึ่งในสิ่งที่ RESTafarians ชอบที่จะถกเถียงกัน

— nategood

233

วิธีมาตรฐานในการส่งรายการค่าเป็นพารามิเตอร์ URL คือทำซ้ำ:

http://our.api.com/Product?id=101404&id=7267261

รหัสเซิร์ฟเวอร์ส่วนใหญ่จะตีความว่านี่เป็นรายการของค่าแม้ว่าหลาย ๆ ค่าจะมีการทำให้เข้าใจง่าย แต่เพียงค่าเดียวดังนั้นคุณอาจต้องดู

ค่าที่คั่นด้วยก็โอเค

หากคุณต้องการส่ง JSON ไปยังเซิร์ฟเวอร์ฉันไม่ชอบที่จะเห็นมันใน URL (ซึ่งเป็นรูปแบบที่แตกต่างกัน) โดยเฉพาะอย่างยิ่ง URL มีข้อ จำกัด ด้านขนาด (ในทางปฏิบัติหากไม่ใช่ในทางทฤษฎี)

วิธีที่ฉันเห็นบางคนทำแบบสอบถามที่ซับซ้อน RESTfully อยู่ในสองขั้นตอน:

POST ความต้องการในการสืบค้นของคุณรับกลับ ID (หลักสร้างทรัพยากรเกณฑ์การค้นหา)
GET การค้นหาโดยอ้างอิง ID ข้างต้น
เลือกลบข้อกำหนดการสืบค้นหากจำเป็น แต่โปรดทราบว่าข้อกำหนดนั้นมีอยู่เพื่อนำมาใช้ซ้ำ

— Kathy Van Stone
แหล่งที่มา

8

ขอบคุณเคธี ฉันคิดว่าฉันอยู่กับคุณและไม่ชอบเห็น JSON ใน URL ด้วย อย่างไรก็ตามฉันไม่ใช่แฟนของที่ทำการโพสต์สำหรับการค้นหาซึ่งเป็นการดำเนินการของ GET โดยธรรมชาติ คุณสามารถชี้ไปที่ตัวอย่างนี้ได้หรือไม่?

— whatupwilly

1

หากแบบสอบถามสามารถทำงานเป็นพารามิเตอร์อย่างง่ายทำ แหล่งมาจากรายการส่งเมล์ที่เหลือ

— Kathy Van Stone

2

หากคุณเพียงต้องการแสดงสองแหล่งข้อมูลคำตอบของ James Westgate นั้นเป็นเรื่องปกติมากขึ้น

— Kathy Van Stone

นี่คือคำตอบที่ถูกต้อง ในอนาคตอันใกล้ฉันแน่ใจว่าเราจะเห็นตัวกรอง = id ใน (a, b, c, ... ) ที่สนับสนุนโดย OData หรืออะไรทำนองนั้น

— บาร์ต Calixto

นี่คือวิธีที่ Akka HTTP ทำงาน

— โจแอนนา

20

ครั้งแรก:

ฉันคิดว่าคุณสามารถทำได้ 2 วิธี

http://our.api.com/Product/<id> : ถ้าคุณต้องการเพียงหนึ่งระเบียน

http://our.api.com/Product : ถ้าคุณต้องการบันทึกทั้งหมด

http://our.api.com/Product/<id1>,<id2> : ตามที่เจมส์แนะนำอาจเป็นตัวเลือกเนื่องจากสิ่งที่เกิดขึ้นหลังจากแท็กผลิตภัณฑ์คือพารามิเตอร์

หรือสิ่งที่ฉันชอบมากที่สุดคือ:

คุณสามารถใช้Hypermedia เป็นเอ็นจิ้นคุณสมบัติของสถานะแอปพลิเคชัน (HATEOAS) ของ RestFul WS และทำการโทรhttp://our.api.com/Productที่ควรส่งคืน URL ที่เทียบเท่าhttp://our.api.com/Product/<id>และเรียกพวกมันต่อจากนี้

ที่สอง

เมื่อคุณต้องทำแบบสอบถามเกี่ยวกับการโทร url ฉันอยากจะแนะนำให้ใช้ HATEOAS อีกครั้ง

1) โทรออกเพื่อรับ http://our.api.com/term/pumas/productType/clothing/color/black

2) โทรออกเพื่อรับ http://our.api.com/term/pumas/productType/clothing,bags/color/black,red

3) (ใช้ HATEOAS) โทรไปที่ ` http://our.api.com/term/pumas/productType/ -> รับ URL เสื้อผ้าที่เป็นไปได้ทั้งหมด -> เรียกสิ่งที่คุณต้องการ (เสื้อผ้าและกระเป๋า) - > รับ URL สีที่เป็นไปได้ -> เรียกสิ่งที่คุณต้องการ

— ดิเอโกเดียส
แหล่งที่มา

1

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

— แซมซั่น

มันขึ้นอยู่กับระบบของคุณจริง ๆ ... ถ้ามันเป็นตัวเลือกที่เรียบง่าย แต่มี "ตัวเลือก" น้อยมากมันน่าจะเกินความจริง อย่างไรก็ตามหากคุณมีรายการที่มีขนาดใหญ่มากอาจทำให้ลำบากในการโทรครั้งใหญ่นอกจากนี้ถ้า API ของคุณเป็นแบบสาธารณะผู้ใช้อาจจะซับซ้อน (ถ้าเป็นแบบส่วนตัวมันควรจะง่ายกว่า ... แค่สอนผู้ใช้ที่คุณรู้จัก) คุณสามารถใช้ทั้งสไตล์, HATEOAS และการเรียก "non-restful array" สำหรับผู้ใช้ขั้นสูง

— Diego Dias

ฉันกำลังสร้าง webservice api ที่สงบใน rails และฉันต้องปฏิบัติตามโครงสร้าง URL เดียวกันกับข้างบน ( our.api.com/term/pumas/productType/clothing/color/black ) แต่ฉันไม่แน่ใจว่าจะกำหนดเส้นทางได้อย่างไร

— rubyist

คำศัพท์ประเภทผลิตภัณฑ์และสีของตัวควบคุมของคุณคืออะไร? ถ้าเป็นเช่นนั้นคุณเพียงแค่ต้องทำ: ทรัพยากร: คำว่าทรัพยากร: ผลิตภัณฑ์ประเภทการทำทรัพยากร: สีที่สิ้นสุด

— Diego Dias

ประเภทผลิตภัณฑ์และสีเป็นพารามิเตอร์ พารามิเตอร์ของผลิตภัณฑ์ประเภทคือเสื้อผ้าและเสื้อผ้าเป็นสีดำ

— rubyist

12

คุณอาจต้องการที่จะตรวจสอบRFC 6570 ข้อมูลจำเพาะเทมเพลต URI นี้แสดงตัวอย่างมากมายว่า URL สามารถมีพารามิเตอร์ได้อย่างไร

— Darrel Miller
แหล่งที่มา

1

ส่วนที่ 3.2.8 ดูเหมือนจะเป็นสิ่งที่ใช้ได้ แม้ว่ามันจะคุ้มค่าที่จะสังเกตว่านี่เป็นเพียงมาตรฐานที่เสนอและดูเหมือนจะไม่ได้ไปไกลกว่าจุดนั้น

— Mike Post

3

@MikePost ตอนนี้ IETF ได้ย้ายไปสู่กระบวนการครบกำหนดสองขั้นตอนสำหรับเอกสาร "ติดตามมาตรฐาน" ฉันคาดว่า 6570 จะอยู่ที่นี่อีกสองสามปีก่อนที่จะย้ายไปที่ "มาตรฐานอินเทอร์เน็ต" tools.ietf.org/html/rfc6410 สเป็คมีความเสถียรอย่างยิ่งมีการใช้งานมากมายและใช้กันอย่างแพร่หลาย

— Darrel Miller

อาฉันไม่รู้ถึงการเปลี่ยนแปลงนั้น (หรือ TIL IETF มีเหตุผลมากกว่านี้) ขอบคุณ!

— Mike Post

8

กรณีแรก:

การค้นหาผลิตภัณฑ์ปกติจะมีลักษณะเช่นนี้

http://our.api.com/product/1

ฉันคิดว่าวิธีปฏิบัติที่ดีที่สุดสำหรับคุณที่จะทำเช่นนี้

http://our.api.com/Product/101404,7267261

กรณีที่สอง

ค้นหาด้วยพารามิเตอร์ตัวกรอง - ปรับอย่างนี้ ฉันจะถูกล่อลวงไปรวมข้อตกลงกับ AND และ OR []แทนการใช้

ป.ล. นี้อาจเป็นเรื่องส่วนตัวดังนั้นทำในสิ่งที่คุณรู้สึกสบายใจ

เหตุผลในการวางข้อมูลลงใน url คือการวางลิงก์ไว้บนไซต์ / แชร์ระหว่างผู้ใช้ หากนี่ไม่ใช่ปัญหาโดยทั้งหมดใช้ JSON / POST แทน

แก้ไข: เมื่อไตร่ตรองฉันคิดว่าวิธีนี้เหมาะสมกับเอนทิตีที่มีคีย์ผสม แต่ไม่ใช่เคียวรีสำหรับหลายเอนทิตี

— James Westgate
แหล่งที่มา

3

แน่นอนว่าในทั้งสองตัวอย่างการติดตาม/ไม่ควรอยู่ที่นั่นเนื่องจาก URI เน้นที่ทรัพยากรไม่ใช่การรวบรวม

— Lawrence Dol

2

ฉันมักจะกริยา HTTP ในการใช้งาน REST นั้นเป็นการกระทำที่เฉพาะเจาะจงและนี่คือบรรทัดคำแนะนำ: GET: ดึงข้อมูล / อ่านวัตถุ, POST สร้างวัตถุ, PUT อัพเดทวัตถุที่มีอยู่และลบลบวัตถุ ดังนั้นฉันจะไม่ใช้ POST เพื่อดึงข้อมูลบางอย่าง ถ้าฉันต้องการรายการของวัตถุโดยเฉพาะ (ตัวกรอง) ฉันจะทำ GET พร้อมกับรายการในพารามิเตอร์ url (คั่นด้วยเครื่องหมายจุลภาคดูเหมือนว่าดี)

— Alex

1

ฉันจะตอบด้วยคำตอบของ nategood เพราะมันสมบูรณ์และดูเหมือนว่าจะมีความต้องการของคุณ แม้ว่าฉันต้องการเพิ่มความคิดเห็นในการระบุทรัพยากร (1 หรือมากกว่า) หลายวิธี:

http://our.api.com/Product/101404,7267261

ในการทำเช่นนั้นคุณ:

ทำให้ซับซ้อนลูกค้า โดยการบังคับให้พวกเขาตีความการตอบสนองของคุณเป็นอาร์เรย์ซึ่งสำหรับฉันนั้นเป็นเรื่องที่เข้าใจง่ายถ้าฉันทำคำขอต่อไปนี้http://our.api.com/Product/101404

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

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

ตัวอย่าง

ฉันต้องการที่จะสั่งซื้อหนังสือจากที่น่าตื่นตาตื่นใจ ฉันรู้ว่ามันคือหนังสือเล่มใดและฉันเห็นมันในรายชื่อเมื่อนำทางไปยังหนังสือสยองขวัญ:

10,000 เส้นที่น่าอัศจรรย์ 0 การทดสอบที่น่าอัศจรรย์
การกลับมาของสัตว์ประหลาดที่น่าทึ่ง
ลองทำซ้ำรหัสที่น่าทึ่ง
จุดเริ่มต้นที่น่าทึ่งของจุดจบ

หลังจากเลือกหนังสือเล่มที่สองฉันถูกเปลี่ยนเส้นทางไปยังหน้ารายละเอียดส่วนหนังสือของรายการ:

--------------------------------------------
Book #1
--------------------------------------------
    Title: The return of the amazing monster
    Summary:
    Pages:
    Publisher:
--------------------------------------------

หรือในหน้าที่ให้รายละเอียดทั้งหมดของหนังสือเล่มนั้นเท่านั้น

---------------------------------
The return of the amazing monster
---------------------------------
Summary:
Pages:
Publisher:
---------------------------------

ความคิดเห็นของฉัน

ฉันขอแนะนำให้ใช้ ID ในตัวแปรพา ธ เมื่อรับประกันความสามัคคีเมื่อรับรายละเอียดของทรัพยากรนี้ ตัวอย่างเช่น API ด้านล่างแนะนำหลายวิธีในการรับรายละเอียดสำหรับทรัพยากรเฉพาะ (สมมติว่าผลิตภัณฑ์มี ID ที่ไม่ซ้ำกันและข้อมูลจำเพาะสำหรับผลิตภัณฑ์นั้นมีชื่อที่ไม่ซ้ำกันและคุณสามารถเลื่อนลงด้านบน):

/products/{id}
/products/{id}/specs/{name}

ช่วงเวลาที่คุณต้องการทรัพยากรมากกว่า 1 ฉันจะแนะนำให้กรองจากชุดใหญ่ สำหรับตัวอย่างเดียวกัน:

/products?ids=

แน่นอนว่านี่เป็นความคิดเห็นของฉันเนื่องจากไม่ได้กำหนดไว้

— gumol
แหล่งที่มา