โครงสร้าง URL RESTful ที่ดีที่สุดสำหรับทรัพยากรแบบเรียกซ้ำคืออะไร

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

ฉันมีข้อกำหนดสามข้อ:

สามารถรับทรัพยากรรูทได้
สามารถรับทรัพยากรส่วนบุคคล
สามารถรับทรัพยากรเด็กได้

ความคิดปัจจุบันของฉันคือ

/rest/documents
/rest/documents/{id}
/rest/documents/{id}/documents

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

ไม่มีใครมีความคิดใด ๆ ข้างต้น? หรือมีวิธีที่แตกต่าง / ดีกว่าในการจัดโครงสร้างสิ่งนี้

web-services

— แมตต์ Brailsford
แหล่งที่มา

ฉันอาจจะเข้าใจผิดคำถาม แต่ในขณะที่เรากำลังพูดถึง URL เป็นปัญหา SEO?

— Jon Hopkins

SEO ไม่ใช่ปัญหาไม่ใช่ ฉันกำลังถามโครงสร้าง URL แบบลอจิกที่ดีที่สุดสำหรับทรัพยากรการอ้างอิงด้วยตนเอง

— Matt Brailsford

ดูเหมือนว่าจะตรงไปตรงมากับฉัน

— Tim Post

โครงสร้างนั้นสามารถไปได้ลึกเพียงใด

— Martijn Verburg

@Martijn ความลึกไม่ จำกัด

— Matt Brailsford

คำตอบ:

สิ่งที่อยู่ในใจของฉันคือ: อย่าปล่อยให้คุณ RESTful API สะท้อนให้เห็นถึงการเกิดซ้ำใน URL ของตัวเอง ลองคิดดูสิแหล่งข้อมูลของคุณเป็นเพียงเอกสารเท่านั้น

หากคุณมีเอกสารของคุณจัดเก็บทางกายภาพตามโครงสร้างแบบเรียกซ้ำให้สร้างการจับคู่กับ ID ที่ไม่ซ้ำกันและใช้ ID ใน URL:

/rest/documents/{id}

ตอนนี้ถ้าคุณมีเอกสารเช่นนี้:

| DocumentName | DocumentPath | DocumentID |
--------------------------------------------
| abc | / abc | 1 |
| asd | / abc / asd | 2 |
| asd | / asd | 3 |
| บู | / abc / asd / boo | 4 |
| เฮ้ / abc / asd / hey | 5 |

คำขอจะศึกษา URL นี้สำหรับ/abc/asdเอกสาร

GET /rest/documents/2

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

{
   data: { /* your document goes here */ },
   parent: {"abc": 1 },
   children: [ { "boo": 4 }, { "hey": 5} ]
}

หากคุณคาดว่าผู้ใช้จะไม่สร้างเอกสารมากเกินไปในระดับเดียวคุณสามารถรวมรายการลูก ๆ ไว้ในการตอบกลับ หากไม่ใช่กรณีดังกล่าวคุณสามารถเสนอให้ผู้ใช้เรียกใช้ ID เอกสารย่อยได้ดังนั้นการอนุญาตให้เพจสามารถแสดงผลลัพธ์ผ่านพารามิเตอร์การสอบถาม:

GET /rest/documents/2/children?page=2&size=50

ในที่สุดการพูดของพารามิเตอร์การสืบค้นคุณสามารถจัดหาข้อมูลเส้นทางโดยตรงผ่านพารามิเตอร์การสืบค้น:

GET /rest/documents?path=somepath&page=1&size=42

วิธีการทั้งหมดที่กล่าวมานั้นคาดว่าGET /rest/documentsจะส่งคืนเอกสารแบบรูทเท่านั้น

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

ความคิดที่ดี. อย่างไรก็ตามความสัมพันธ์กับเอกสารย่อยไม่ชัดเจนจาก API หากเอกสารลูกรวมอยู่ในการตอบกลับเอกสาร หากเอกสารมีแหล่งข้อมูลย่อยอื่นเช่นความคิดเห็นโดยทั่วไปคุณจะสามารถเข้าถึงคำถามสำหรับเอกสารโดยใช้ / Documents / {id} / คำถาม เพื่อให้สอดคล้องและทำให้ความสัมพันธ์กับเอกสารย่อยชัดเจนใน API ฉันขอแนะนำให้เข้าถึงเอกสารย่อยโดย / documents / {id} / เอกสารย่อย การรับรองที่ส่งคืนจะเป็นเอกสารเช่นเดียวกับ / Documents / {id} ดังนั้นส่วนที่เหลือของสิ่งที่คุณอธิบายที่นี่ยังใช้งานได้

— นาธานวอร์ด

บางสิ่งเช่นนี้อาจจะ:

/rest/{rootEntity}/Item/{leafEntity}/{id}
/rest/{entity}/ItemList
/rest/{entity}/ItemList/{leafEntity}

โดยที่ {rootEntity} เป็นจุดเริ่มต้นของคอลเลกชันของคุณ {leafEntity} คือโหนดใบที่มีชื่อใด ๆ ภายในต้นไม้ของคุณ

คุณสามารถเพิ่มพารามิเตอร์สองสามข้อต่อไปนี้เพื่อเลือกพูดล่าสุดหรือทั้งหมดหรือบางอย่าง

— Gary Rowe
แหล่งที่มา