ควรใช้ทรัพยากรที่ซ้อนอยู่ใน RESTful API เมื่อใด

ฉันมีสองแหล่งข้อมูล: ผู้ใช้และลิงก์

ผู้ใช้สามารถมีหลายลิงค์ที่เกี่ยวข้อง ฉันได้ออกแบบ RESTful API ของฉันเพื่อให้คุณสามารถเข้าถึงลิงก์ที่เกี่ยวข้องกับผู้ใช้ได้ที่ URI ต่อไปนี้:

/users/:id/links

อย่างไรก็ตามฉันจำเป็นต้องมี URI เสมอสำหรับลิงก์ - บางครั้งฉันอาจต้องการลิงก์ทั้งหมดโดยไม่คำนึงถึงผู้ใช้

สำหรับสิ่งนี้ฉันมี:

/links

เสียงนี้ใช้ได้ไหม? มี URI สองตัวสำหรับลิงก์หรือไม่

ฉันสงสัยว่าฉันควรเข้าถึงลิงก์สำหรับผู้ใช้ที่มี URI หรือไม่เช่น:

/links/user/:id หรือ /links/?user=:id

ด้วยวิธีนี้ฉันมีแหล่งข้อมูลเพียงแหล่งเดียวสำหรับลิงก์

api rest api-design

— Oliver Joseph Ash
แหล่งที่มา

อืม .. อันนี้ดูหรูหรามากขึ้น:/links/user/:id

— theMarceloR

@theMarceloR: นั่นเป็นเพียงตัวอย่างเดียวจากสามข้อที่ฉันไม่เข้าใจชัดเจนเป็นพิเศษ เป็นทรัพยากรสำหรับลิงค์หรือผู้ใช้หรือไม่ URI นั้นมีความคลุมเครือน้อยกว่ามากโดยใช้เมธอดทรัพยากรที่ซ้อนกัน ( /users/:id/links) หรือเมธอดสตริงการสืบค้น ( /links/?user=:id) เนื่องจากจริง ๆ แล้วมันเป็นเคียวรี /links/user/:idอาจดูดีและ / หรือง่ายกว่าในการกำหนดเส้นทางในบางกรอบ แต่จริงๆแล้วค่อนข้างสับสน

— Aaronaught

ไม่ไม่มีอะไรผิดปกติกับการมีหลายแหล่งข้อมูลสำหรับ "สิ่งเดียวกัน" ในรายการกรณีนี้ลิงก์

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

/links -- all links
/links/:linkid -- a particular link

จากนั้นตัวกรองในคอลเลกชันลิงก์จะแสดงเป็นพารามิเตอร์ข้อความค้นหา เพื่อรับลิงค์ของผู้ใช้บางท่านคุณจะใช้:

/links?user=/users/:userid

สิ่งนี้ยังช่วยให้การจัดองค์ประกอบของตัวกรองง่ายขึ้น:

/links?user=/users/10&since=2013-01-01

และมันเป็นเรื่องง่ายที่จะเข้าใจแนวคิด - คุณมีชุดรายการและคุณเพิ่มตัวกรอง

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

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

"ทรัพยากรทั้งหมดที่ไม่มีความเข้มงวดในการเป็นเจ้าของไม่ควรซ้อน" ดูเหมือนเป็นกฎที่ดี ขอบคุณมัด

— Oliver Joseph Ash

ผมบอกว่ามีเป็นบางอย่างผิดปกติกับการมีทรัพยากรที่หลากหลายสำหรับนิติบุคคลกายภาพเดียวกัน แต่ที่ไม่จริงนี่คืออะไร แต่ละลิงก์แต่ละอันมี URL ตามรูปแบบบัญญัติ (links /: id) ในขณะที่แต่ละแหล่งข้อมูลข้างต้นเป็นแหล่งข้อมูลเดียว (/ ลิงก์) ที่มีการใช้ตัวกรอง นอกจากนี้ฉันประหลาดใจโดย?user=users/:useridในสตริงแบบสอบถาม; มีอะไรผิดปกติกับ?userid=:userid?

— Aaronaught

@Aaraught: เหตุผลในการยึดติดกับ uri แทน id เปล่าคือเพื่อให้ลูกค้าสามารถปฏิบัติต่อตัวระบุทรัพยากรทั้งหมดอย่างเท่าเทียมกันนั่นคือลูกค้าต้องการเพียงรู้ว่า 'ผู้ใช้นี้ถูกระบุโดย"/*******"; จุดที่*ทึบแสง แต่ตัวระบุเดียวกันนั้นสามารถใช้เพื่ออ้างถึงทรัพยากรนั้น (เช่นเดียวกับลิงค์) เสมอเพื่อดึงข้อมูลเวอร์ชันล่าสุดของทรัพยากรนั้นและอื่น ๆ เนื้อหาของ uri นั้นเข้าใจโดยเซิร์ฟเวอร์ต้นทางเท่านั้น นี่ก็หมายความว่าหากตัวระบุจำเป็นต้องเปลี่ยนพูด/realm/:businessid/users/:idลูกค้าก็ไม่ได้เปลี่ยนแปลงเลย

— SingleNegationElimination

@TokenMacGuy: ขออภัยฉันไม่เข้าใจส่วนหนึ่งของความคิดเห็นของคุณ ความแตกต่างระหว่างจริง/users/:userid/linksกับ/links?userid=:useridอะไร ในทั้งสองกรณีตัวระบุจะไม่เปลี่ยนแปลงพวกเขาดึงข้อมูลเวอร์ชันปัจจุบันของทรัพยากรนั้นและลูกค้าปฏิบัติต่อพวกเขาในลักษณะเดียวกัน ไม่มีสิ่งใดเป็น URL แบบบัญญัติสำหรับสิ่งนี้เพราะมันไม่ใช่ทรัพยากร แต่เป็นคิวรี่ดังนั้นนี่เป็นไวยากรณ์เคียวรีสองประเภทที่แตกต่างกัน ฉันยังไม่ชัดเจนว่าลูกค้าไม่จำเป็นต้องเปลี่ยนแปลงอย่างไรหากโครงสร้าง URL เปลี่ยนแปลง ที่ถือว่าเป็นการเปลี่ยนแปลงที่รุนแรงใน REST เว้นแต่ว่าจะมี 301 รายการอยู่

— Aaronaught

@Aaraught: ฉันอาจเข้าใจผิดเกี่ยวกับความกังวลของคุณ หาก/linksสนับสนุนอินเทอร์เฟซแบบสอบถาม/links?user=/users/123อนุญาตให้ใช้แนวทางตัวดำในการระบุทรัพยากรในไคลเอ็นต์ที่/links?userid=123ไม่ได้ หลังลูกค้าต้องเข้าใจสิ่งที่หมายเลขผู้ใช้และวิธีการที่จะได้รับมันน่าจะออกมาจากทรัพยากรที่ได้รับจากการหรือ/users/123 /links/456/userอดีตหมายถึงลูกค้าสามารถใช้ uri ไม่ได้แก้ไข; สมมติว่า/links/.../userคำตอบนั้นให้การตอบโต้สื่อหลายมิติ (พูดกับLocation:ส่วนหัว)

— เจรจาต่อรองเดี่ยวสิ้นสุด

ดังนั้นความกังวลของฉันคือ: / users /: userid / links คืน "links" แต่ถ้า user_id ไม่ได้ระบุสิ่งนี้ควรส่งคืน 404

อย่างไรก็ตาม

/ links? userid =: userid อาจส่งคืนรายการว่าง (โดยปกติคือ 200) ซึ่งจริงๆแล้วอาจเป็นจุดบกพร่อง และค่อนข้างเป็นไปได้

แม้ว่าทั้งสองจะทำงาน แต่การซ้อนจะให้ฟังก์ชันการทำงานเพิ่มเติมที่คุณสามารถวาดในภายหลัง

— Richard Browne
แหล่งที่มา