URI ทรัพยากรควรอ่านออกมาเหมือน เส้นทางที่ใช้คำนามชี้ไปยัง "สิ่งของ" ไม่ใช่การกระทำ HTTP method ให้คำกริยามาแล้ว ดังนั้น URI จึงเพียงแค่ต้องระบุทรัพยากรให้ชัดเจนและสอดคล้องกัน
URI ทรัพยากรควรอ่านออกมาเหมือน เส้นทางที่ใช้คำนามชี้ไปยัง "สิ่งของ" ไม่ใช่การกระทำ HTTP method ให้คำกริยามาแล้ว ดังนั้น URI จึงเพียงแค่ต้องระบุทรัพยากรให้ชัดเจนและสอดคล้องกัน
GET /users/42 — ไม่ใช่ GET /getUser?id=42 method (GET) คือคำกริยา/users คือ collection; /users/42 คือสมาชิกหนึ่งราย การคงพหูพจน์ทุกที่ทำให้คาดเดาได้/users/42/orders = "order ที่เป็นของ user 42"kebab-case และตัวพิมพ์เล็ก /blog-posts ไม่ใช่ /blogPosts หรือ /Blog_Posts/users?role=admin&sort=-created_at/users collection of users
/users/42 a single user
/users/42/orders orders belonging to user 42 (sub-collection)
/users/42/orders/1001 a specific order of that user
/orders/1001 same order, addressable at top level too
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
หลีกเลี่ยงการซ้อนลึกเกินหนึ่งถึงสองระดับ — /users/42/orders/1001/items/5/reviews จะเปราะบาง เมื่อ order มี ID ของตัวเองแล้ว ให้เลือกใช้ /orders/1001 สำหรับการกระทำที่ไม่เข้ากับ CRUD (เช่น "ส่งอีเมล") sub-resource สไตล์ controller เป็นที่ยอมรับได้: POST /users/42/verify-email
การตั้งชื่อที่สอดคล้องกันคือสิ่งที่ทำให้ API รู้สึกเป็นธรรมชาติ — นักพัฒนาที่เห็น /users และ /users/42 แล้ว ย่อมเดา /products และ /products/99 ได้ถูกต้องโดยไม่ต้องอ่านเอกสาร ผู้สัมภาษณ์ใช้ข้อนี้ประเมินว่าคุณคิดในแง่ ทรัพยากร (กรอบคิดแบบ REST) หรือในแง่ RPC call (/doThisThing) anti-pattern ที่พบบ่อยที่สุด — คำกริยาใน path, พหูพจน์/เอกพจน์ไม่สอดคล้อง, และ URL ซ้อนลึก — ล้วนทำให้ API เรียนรู้และดูแลยากขึ้น และบ่งบอกถึงนักพัฒนาที่ยังไม่ซึมซับข้อจำกัด uniform-interface ของ REST การออกแบบ URI ที่ดียังแยกความกังวลออกจากกัน: การระบุตัวตนอยู่ใน path, การกรองและการแบ่งหน้าอยู่ใน query string ซึ่งทำให้ caching และ routing สะอาด
คลังคำถามสัมภาษณ์งาน IT พร้อมคำตอบโดยละเอียด — ตั้งแต่ระดับ Junior ถึง Senior
บริจาค