สแลชต่อท้ายใน RESTful API

ฉันได้มีการถกเถียงกันว่าจะทำอย่างไรกับการต่อท้ายสแลชใน RESTful API

ให้บอกว่าฉันมีทรัพยากรที่เรียกว่าสุนัขและทรัพยากรรองสำหรับสุนัขแต่ละตัว ดังนั้นเราสามารถทำสิ่งต่อไปนี้:

GET/PUT/POST/DELETE http://example.com/dogs
GET/PUT/POST/DELETE http://example.com/dogs/{id}

แต่เราจะทำอย่างไรกับกรณีพิเศษต่อไปนี้:

GET/PUT/POST/DELETE http://example.com/dogs/

มุมมองส่วนตัวของฉันคือว่าเรื่องนี้ไม่ว่าจะเป็นส่งคำขอไปเป็นทรัพยากรบุคคลที่มีสุนัข id null= ฉันคิดว่า API ควรส่งคืน 404 สำหรับกรณีนี้

บางคนบอกว่าคำขอกำลังเข้าถึงทรัพยากรสุนัขนั่นก็คือละเว้นการต่อท้ายสแลชจะถูกละเว้น

ไม่มีใครรู้คำตอบที่ชัดเจน?

api rest http

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

ฉันคิดว่าวิธีที่สงบคือการแยกแยะระหว่างสุนัข / ไอดีและสุนัข (หมายถึงสุนัขทุกตัว)

— สาธารณรัฐประชาธิปไตยประชาชนลาว

จาก RESTful Web Services หนังสือ - ทรัพยากรรอง: ทรัพยากรที่มีอยู่ในความสัมพันธ์กับทรัพยากร "หลัก" อื่น ๆ เช่น Dogs / {id} ฐานข้อมูลที่เปิดใช้งานเว็บอาจเปิดเผยตารางเป็นทรัพยากรและแถวฐานข้อมูลแต่ละรายการเป็นทรัพยากรรอง .

— Gaz_Edge

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

— Benjamin Gruenbaum

ฉันไม่ติดตาม - ใครบอกว่าคุณไม่สามารถลบสุนัขได้? หากคุณลบสุนัขมันจะลบตัวเองและสุนัขแต่ละตัว นั่นเป็นเหตุผลที่ฉันคิดว่าการอนุญาตให้โทรหาสุนัข / มีความเสี่ยง จะเกิดอะไรขึ้นถ้าลูกค้าตั้งใจจะลบสุนัขแต่ละตัว แต่ตั้งใจทิ้ง {id} โดยไม่ตั้งใจ ผลที่ได้คือสุนัขทุกตัวจะถูกลบ ปลอดภัยกว่าที่คิดว่าจะขอ {id} เป็นโมฆะและส่งคืน 404

— Gaz_Edge

ฉันจะปฏิบัติต่อdogsและdogs/เท่าเทียมกัน สำหรับฉันมันชัดเจนว่าdogs/เป็นไดเรกทอรีที่มีสุนัขแต่ละตัว มันไม่ชัดเจนสิ่งที่dogsเป็น /แต่ฉันรักษามันเป็นเทียบเท่าเช่นเดียวกับเว็บเซิร์ฟเวอร์ส่วนใหญ่ยอมรับการเข้าถึงไปยังไดเรกทอรีโดยไม่ต้องต่อท้าย

— CodesInChaos

คำตอบ:

สิ่งนี้ไม่มีสิทธิ์ (เนื่องจาก REST ไม่มีความหมายที่แน่นอน) แต่จากรายงานต้นฉบับบน REST URL แบบเต็ม (ไม่สิ้นสุดใน /) ตั้งชื่อทรัพยากรในขณะที่อีกหนึ่งลงท้ายด้วยเครื่องหมายทับ '/' เป็นกลุ่มทรัพยากร (อาจไม่พูดแบบนั้น)

GET ของ URL ที่มีสแลชที่ส่วนท้ายควรจะแสดงรายการทรัพยากรที่มีอยู่

GET http://example.com/dogs/          /* List all the dogs resources */

PUT บน URL ที่มีเครื่องหมายทับควรจะแทนที่ทรัพยากรทั้งหมด

PUT http://example.com/dogs/          /* Replace all the dogs resources */

การลบใน URL ที่มีเครื่องหมายทับควรจะลบทรัพยากรทั้งหมด

DELETE http://example.com/dogs/       /* Deletes all the dogs resources */

POST บน URL ที่มีเครื่องหมายทับควรจะสร้างทรัพยากรใหม่จากนั้นสามารถเข้าถึงได้ในภายหลัง เพื่อให้สอดคล้องกับทรัพยากรใหม่ควรอยู่ในไดเรกทอรีนี้ (แม้ว่าสถาปัตยกรรม RESTful จะโกงที่นี่)

POST http://example.com/dogs/        /* Creates a new dogs resource (notice singular) */

เป็นต้น

หน้า wiki ในหัวเรื่องดูเหมือนจะอธิบายได้ดี:

ดูตัวอย่างhttps://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_services

— มาร์ตินยอ
แหล่งที่มา

นอกจากนี้ยังเหมาะกับรูปแบบเส้นทาง / URL ปกติซึ่งไดเรกทอรีมักจะเขียนด้วยการต่อท้าย/

— CodesInChaos

ดังนั้นจะเกิดอะไรขึ้นถ้าคุณเข้าถึงกลุ่มทรัพยากรโดยไม่มีการติดตาม/?

— oberlies

@oberlies: มันขึ้นอยู่กับบริบท ไม่มีกฎที่ยากและรวดเร็วเพียงแนวทางปฏิบัติที่ดีที่สุดเท่านั้น มี expcetions กฎเสมอและควรหมายถึงสิ่งที่คุณคาดหวังว่าจะหมายถึง ในตัวอย่างด้านบน: GET http://example.com/dogsอาจส่งคืนข้อมูลเมตาเกี่ยวกับสุนัข (ไม่ใช่รายการ แต่เป็นข้อมูลเมตาเกี่ยวกับรายชื่อสุนัข) บางทีมันอาจจะเป็นข้อผิดพลาด

— Martin York

As the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. It’s better to drop them completely.

นี่ไม่ใช่สถานที่เดียวที่แนะนำว่าอย่าใช้สแลชฝึกอบรม

— Laiv

@ Laiv ฉันไม่เห็นด้วยกับความเชื่อมั่น แต่โปรดเชื่อมโยงข้อมูลอ้างอิงที่เชื่อถือได้มากขึ้น (นั่นคือลิงค์ที่อ่อนแอ)

— มาร์ตินยอร์ค

Does anyone know the definitive answer?

ไม่มีเพราะไม่มีเอกสารอย่างเป็นทางการเกี่ยวกับสิ่งที่จำเป็นสำหรับบริการที่จะถือว่าสงบ

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

— ไมค์
แหล่งที่มา

สิ่งที่เกี่ยวกับ DELETE example.com/dogs ?

— Benjamin Gruenbaum

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

— Gaz_Edge

@Gaz_Edge: ในส่วนที่เหลือเป็นทรัพยากรอิสระอย่างสมบูรณ์ของทรัพยากรใดexample.com/dogs ๆ example.com/dogs/Xดังนั้นการลบexample.com/dogsจะไม่ต้องลบสุนัขทั้งหมด / * (แม้ว่าจะเป็นความหมาย) แต่ DELETE example.com/dogs/ควรลบสุนัขทั้งหมด / *

— Martin York

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

— Mike

ฉันรู้ว่านี่เป็นหัวข้อเก่า แต่ฉันเพิ่งสงสัยเกี่ยวกับเรื่องนี้ด้วยตัวเอง สำหรับสิ่งที่คุ้มค่าที่ถือว่า OS X เปลือกทุบตีfoo, foo/และfoo////เหมือนกัน ดูเหมือนว่าโดยทั่วไปแล้วจะตัดส่วนของเส้นทางที่ว่างเปล่าออก ดังนั้นหากคุณปฏิบัติตามแนวทางเดียวกันกับบริการ REST ของคุณdogsและdogs/จะอ้างถึงสิ่งเดียวกัน

— Greg Brown

สองทาง.

วิธีที่ 1

ใช้เครื่องหมายทับต่อท้ายเสมอสำหรับทรัพยากรใด ๆ ที่อาจมีลูก

เพียงพิจารณา "GET" ในไดเรกทอรี public_html ด้วยไฟล์

เป็นไปไม่ได้เมื่อ hello.html เป็นไฟล์:

/hello.html
/hello.html/youagain.html

แต่เป็นไปได้เมื่อ hello.html เป็นไดเรกทอรี:

/hello.html/     (actually /hello.html/index.html)
/hello.html/youagain.html

ดังนั้นหาก "hello.html" สามารถมีลูกได้ก็จะเป็นตลอดไปและตลอดไป "/hello.html/" และ "/hello.html/index.html" (หรือเพียงแค่ /hello.html/) เป็นรายการของเด็ก ๆ เหล่านี้ .

วิธีที่ 2

ฉลาด".

$ find
.
./hello.html
./hello.html/index.html

คำสั่ง find ไม่สนใจประเภทของ hello.html ไดเรกทอรีหรือไฟล์ที่ใส่ใจมันเป็นชื่อของวัตถุ เมื่อเราเขียน "cp youagain.html hello.html" cp สามารถหาวิธีจัดการ hello.html cp ฉลาด เว็บเซิร์ฟเวอร์ของคุณก็ฉลาดเช่นกัน มันมีห้องสมุดการจัดการเส้นทาง มันมีเส้นทาง มันสามารถสถิติและบอกคุณว่าชื่อเป็นวัตถุหรือไดเรกทอรี มันสามารถเปลี่ยนเส้นทาง blah ไปเป็น blah / หรือแม้กระทั่งตอบสนองการตอบสนองที่เหมือนกันสำหรับทั้งสอง นี่คือสิ่งที่ยอดเยี่ยม !!! ทาง เทคโนโลยีมาก ใครที่เคยต้องการที่จะเชื่อมโยงสตริงเส้นทางง่ายๆเมื่อเราสามารถทำสิ่งนั้นได้ทั้งหมด ???

— ซามูเอลแดเนียล
แหล่งที่มา