URI tài nguyên nên đọc như một đường dẫn bằng danh từ tới một "thứ", không phải một hành động. HTTP method đã cung cấp động từ rồi, nên URI chỉ cần định danh tài nguyên rõ ràng và nhất quán.
URI tài nguyên nên đọc như một đường dẫn bằng danh từ tới một "thứ", không phải một hành động. HTTP method đã cung cấp động từ rồi, nên URI chỉ cần định danh tài nguyên rõ ràng và nhất quán.
GET /users/42 — không phải GET /getUser?id=42. Method (GET) chính là động từ./users là collection; /users/42 là một phần tử. Giữ số nhiều ở mọi nơi cho dễ đoán./users/42/orders = "các order thuộc user 42".kebab-case, viết thường. /blog-posts, không phải /blogPosts hay /Blog_Posts./users?role=admin&sort=-created_at./users collection các user
/users/42 một user
/users/42/orders order thuộc user 42 (sub-collection)
/users/42/orders/1001 một order cụ thể của user đó
/orders/1001 cùng order đó, cũng truy cập được ở top level
GET /users/42/orders?status=shipped&sort=-created_at&page=2 HTTP/1.1
Accept: application/json
Tránh lồng sâu quá một hai cấp — /users/42/orders/1001/items/5/reviews trở nên mong manh. Khi order đã có ID riêng, ưu tiên /orders/1001. Với hành động không hợp CRUD (vd. "gửi email"), một sub-resource kiểu controller là chấp nhận được: POST /users/42/verify-email.
Đặt tên nhất quán làm API trở nên trực giác — lập trình viên đã thấy /users và /users/42 có thể đoán đúng /products và /products/99 mà không cần đọc tài liệu. Người phỏng vấn dùng câu này để đánh giá bạn có tư duy theo tài nguyên (tư duy REST) hay theo RPC call (/doThisThing). Các anti-pattern phổ biến nhất — động từ trong path, số nhiều/số ít không nhất quán, và URL lồng sâu — đều làm API khó học và khó bảo trì, và cho thấy lập trình viên chưa thấm ràng buộc uniform-interface của REST. Thiết kế URI tốt cũng tách bạch mối quan tâm: định danh nằm ở path, filter và phân trang nằm ở query string, giúp caching và routing sạch sẽ.
Thư viện câu hỏi phỏng vấn IT với đáp án chi tiết — từ Junior đến Senior.
Ủng hộ