Trộn REST API số nhiều và số ít cho các tài nguyên khác nhau?

Question

Dạng số nhiều cho REST api là tự nhiên hơn và được sử dụng nhiều hơn, ví dụ: /api/users hoặc api/users/123.

Nhưng đối với một số tài nguyên không phải là ví dụ tự nhiên:

• /api/login - đăng nhập vào chính xác một người dùng
• /api/profile - nhận hồ sơ của người dùng đăng nhập

nguồn lực này sẽ không bao giờ được sử dụng để biết thêm một đối tượng/mô hình trong ứng dụng của tôi.

Mặt khác, tôi đọc rằng việc trộn biểu mẫu số nhiều và số ít trong tên tài nguyên không phải là thực hành tốt (http://pages.apigee.com/web-api-design-ebook.html).

Vì vậy, tôi xem xét những việc cần làm:

1. sử dụng đơn lẻ cho tất cả số nhiều
2. sử dụng cho tất cả (với một số hình thức ngu ngốc như /api/logins)
3. không phù hợp và sử dụng số nhiều cho hầu hết các nguồn tài nguyên mong đợi một số tài nguyên đặc biệt như /api/login hoặc /api/profile luôn được sử dụng với một đối tượng/mô hình.

Cách tiếp cận tốt hơn là gì?

Answer 1

Không có nguyên tắc nghiêm ngặt để xác định API RESTful, nhưng những gì tôi đọc nhiều nhất là cảm giác thông thường phải có phần trên.

Do đó, tùy chọn 3:

không phù hợp và sử dụng số nhiều cho hầu hết các nguồn tài nguyên mong đợi một số tài nguyên đặc biệt như/api/login hoặc/api/profile mà luôn được sử dụng với một đối tượng/mô hình.

là hợp lý nhất. Bạn luôn có thể đoán URL khi bạn nghĩ "Tôi cần tài nguyên X, URL này trông như thế nào"?

Answer 2

REST (Chuyển trạng thái đại diện) về cơ bản là cho một thực thể duy nhất và để thực hiện CRUD trên đó. Vì vậy, sử dụng số ít có ý nghĩa hơn với tôi. Nhưng trong trường hợp khi bạn cần phải có được danh sách thì số nhiều có ý nghĩa. Ví dụ:

Bạn muốn có được một người dùng sau đó có/api/người dùng/{id}

Nhưng nếu bạn muốn để có được danh sách người dùng sau đó có/api/người dùng

Answer 3

Tôi không nói tôi thích số nhiều, nhưng nếu bạn đang đi với số nhiều bạn có thể hòa giải các thông tin đặc biệt của bạn theo cách này:

GET /api/forms/login là biểu mẫu đăng nhập HTML. Sử dụng phối cảnh này, login là ID của chỉ một biểu mẫu trong một bộ sưu tập biểu mẫu.

POST /api/forms/login là nơi gửi biểu mẫu đăng nhập.

GET /api/users/{id}/profile truy xuất hồ sơ của người dùng được chỉ định.Điều này làm việc cho rất nhiều trường hợp nhưng không hoạt động cho các trang ẩn danh, nơi danh tính của người dùng sẽ vẫn bị ẩn ngay cả khi xem hồ sơ của họ, có thể bỏ qua ID người dùng và tên thật của họ.

GET /api/profiles/{id} tách riêng thực thể hồ sơ khỏi ID người dùng và sẽ hoạt động cho trang web ẩn danh.

Hoặc, bạn có thể viết GET /api/users/current/profile hoặc GET /api/sessions/current/profile bỏ qua ID cụ thể như trong bài đăng của bạn vì máy chủ sẽ trả lời bằng nội dung có liên quan đến người dùng hiện tại.

Answer 4

Những gì tôi đã nhìn thấy trong một số dự án Tôi đã làm việc trên những năm này là vẻ bề ngoài ít thân thiện hơn cho hầu hết các hoạt động phổ biến, bạn có thể có ví dụ như các thiết bị đầu cuối sau cho tài nguyên sử dụng:

GET /user --> retrieves all users 
GET /user/{id} --> retrieves a user with the given id 
POST /user --> inserts a new user (the user object will come in the request body) 
PUT /user/{id} --> updates a user with the given id (the user object will come in the request body) 
DELETE /user/{id} --> deletes the user with the given id 

đó là những hoạt động phổ biến, khi bạn có số lượng lớn chèn/cập nhật/xóa các hoạt động sau đó nó nên được tốt hơn để sử dụng số nhiều

POST /users (the user objects will come in the request body) 
PUT /users/{listOfIds} (the user objects will come in the request body) 
DELETE /users/{listOfIds} 

GET/người dùng và GET/người sử dụng sẽ là từ đồng nghĩa, hai sẽ chấp nhận tham số truy vấn để tinh chỉnh kết quả, ví dụ

GET /users?status=active