Cách thích hợp để lồng các tài nguyên trong mô hình REST là gì?


14

Tôi đang thiết kế API REST của dịch vụ và bị mắc kẹt trên cách thích hợp để lồng tài nguyên.

Tài nguyên: đối tác, vé, cài đặt

Kết nối giữa các tài nguyên:

  • Đối tác có nhiều vé,
  • Đối tác đã thiết lập cài đặt,

Logic kinh doanh:

  • bạn có thể liệt kê tất cả các đối tác là người dùng ẩn danh,
  • bạn có thể thêm vé mới cho đối tác được chỉ định là người dùng ẩn danh,
  • chỉ đối tác mới có thể liệt kê vé của mình,
  • chỉ đối tác mới có thể sửa đổi vé của mình,
  • chỉ đối tác mới có thể liệt kê các cài đặt,
  • chỉ đối tác mới có thể sửa đổi cài đặt,

Những gì tôi đã làm cho đến bây giờ:

Tài nguyên đối tác

NHẬN / đối tác - liệt kê tất cả các đối tác
GET / đối tác /: id - hiển thị chi tiết về đối tác được chỉ định bởi: tham số id
GET / đối tác /: đối tác_id / vé - danh sách vé của đối tác
GET / đối tác /: đối tác_id / vé /: id - chi tiết của vé đối tác được chỉ định
POST / đối tác /: Partner_id / Ticket - lưu vé mới
PUT / đối tác /: Partner_id / Ticket /: id - cập nhật vé được chỉ định bởi: tham số id
GET / đối tác /: Partner_id / settings - liệt kê cài đặt của đối tác
PUT / đối tác /: Partner_id / settings - cập nhật cài đặt của đối tác

Vấn đề / câu hỏi

Sẽ là cách thích hợp để phân chia tài nguyên lồng nhau (vé, cài đặt) để phân tách tài nguyên hoặc sao chép chúng dưới dạng tài nguyên riêng biệt?

Ví dụ

NHẬN / vé /: id
BÀI / vé
PUT / vé /: id

NHẬN / cài đặt
PUT / cài đặt

Câu trả lời:


8

NGÀY :

GET /partners/:partner_id/tickets - danh sách vé của đối tác, nghĩa là trả về danh sách các URI, có thể có dạng /tickets/:id

GET /partners/:partner_id/tickets/:id - không cần thiết

POST /partners/:partner_id/tickets - tạo một vé và liên kết với đối tác, trả về một năm 201 với URI mới, có dạng /tickets/:id


2
Bây giờ tôi đã hiểu nhiều hơn. Cảm ơn rất nhiều :) Nhưng còn hiệu suất thì sao? Giả sử tình huống đó: bạn muốn tạo danh sách vé với một số thông tin ngắn. Bạn phải yêu cầu danh sách vé cho đối tác và sau đó yêu cầu từng vé riêng lẻ. Tôi có đúng không
Przemek

tốt, vâng hoặc bạn có thể tạo /partners/:partner_id/ticketsdanh sách bao gồm một số dữ liệu hữu ích cho mỗi vé, không chỉ URI chính tắc của vé. Ví dụ, trong JSON có thể là [{href='/tickets/12',value=10,due='2013-08-13'},{href='/tickets/18',value=7,due='2013-09-02'}], do đó, máy khách có thể hiển thị ngay một số bảng và NHẬN / ĐẶT (các) tài nguyên vé đầy đủ để thao tác thêm.
Javier

OK Rõ rồi.
Przemek

BTW. Đối với / đối tác /: Partner_id / vé nên cung cấp tài liệu trong phần tài nguyên đối tác hoặc vé?
Przemek

@Javier còn gì về XÓA? DELETE /tickets/:id?
Mạnhdi Gao
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.