Có hợp lý cho các tài nguyên REST là số ít và số nhiều không?

Tôi đã tự hỏi nếu, thay vì một bố cục truyền thống như thế này:

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

Nó sẽ hữu ích hơn khi có một số ít và số nhiều, ví dụ:

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

Vì vậy, để tạo ra một bộ sưu tập các sản phẩm bạn có thể làm:

POST api/Products {data: filters} // returns api/Products/<id>

Và sau đó, để tham khảo nó, bạn có thể làm:

GET api/Products/<id> // returns array of products

Theo tôi, ưu điểm chính của việc thực hiện theo cách này là cho phép dễ dàng lưu trữ bộ sưu tập các sản phẩm. Chẳng hạn, người ta có thể đặt thời gian một giờ cho các bộ sưu tập sản phẩm, do đó giảm đáng kể các cuộc gọi trên máy chủ. Tất nhiên, hiện tại tôi chỉ thấy mặt tốt của việc làm theo cách này, nhược điểm là gì?

rest

— Eva
nguồn

Câu trả lời:

Thông thường khi một bộ sưu tập sẽ là cách tương tác hữu ích nhất với api của bạn, có thể đơn giản hơn khi chỉ nghĩ một bộ sưu tập là một bộ sưu tập chỉ có một thành viên. Sau đó, nếu sau này bạn muốn trưng ra một API để tương tác với các đĩa đơn, thì nó chỉ cần dưới vỏ bọc chuyển đổi một đĩa được chuyển vào một bộ sưu tập với thành viên đó và sau đó nó sử dụng cách triển khai API khác.

Tôi đoán điều tôi đang nói ở đây là, nếu bạn muốn các bộ sưu tập là một cơ chế tương tác, hãy bắt đầu với API chỉ bộ sưu tập và sau khi hệ thống hoàn tất, API khác là một phụ kiện đơn giản ở lớp giao diện mà bạn có thể thêm vào sau đó nếu bạn thấy nó đặc biệt hữu ích Tuy nhiên, bạn có thể thấy tính hữu dụng của nó đủ tối thiểu để áp dụng YAGNI và chỉ cần sử dụng giao diện bộ sưu tập cho một vài trường hợp bạn muốn.

— Jimmy Hoffa
nguồn

Mặc dù tôi đồng ý với tình cảm của bạn, giả sử rằng chúng tôi sử dụng ví dụ trên, cho rằng POST api / Sản phẩm sẽ được sử dụng để truyền tham số bộ lọc bộ sưu tập và không phải dữ liệu để tạo sản phẩm mới, đâu là cách hợp lý để tạo sản phẩm mới không có api / sản phẩm?

— Eva

@Evan Tại sao không thể đăng lên api / Sản phẩm chèn nhiều (hoặc bộ sưu tập một) Sản phẩm? Điều đó có vẻ hợp lý nhất với tôi. Có lẽ đăng Sản phẩm / Bộ lọc để tạo bộ lọc hoặc nhận nếu chúng là nhiệm vụ truy xuất và không phải là tác vụ.

— Jimmy Hoffa

Cảm ơn vì sự công phu, Jimmy. Lý do tôi không thấy nó theo cách này là vì tôi đã xem xét, trong ví dụ trên, bộ sưu tập như là một tài nguyên được xác định trong chính nó. Trong phần phụ trợ, api / Sản phẩm có thể là "Sản phẩm" và api / Sản phẩm là "ProductCollection". Tuy nhiên, sau khi xem xét, tôi nghĩ có thể tốt hơn là trừu tượng hóa tất cả khỏi API, như trong đề xuất của bạn ... bây giờ với câu hỏi thực sự, bạn đã lái xe từ trạm dừng xe tải đó đến Thái Lan hay rời khỏi Thái Lan trong cốp xe?

— Eva

@Evan Tôi sẽ cho bạn hai gợi ý: Hải âu.

— Jimmy Hoffa

Nhược điểm là chương trình gọi cũng phải đa dạng hóa tên tài nguyên, điều này có thể gây khó khăn cho những ngôn ngữ máy khách không có cơ chế đa nguyên hóa tích hợp. Nếu bạn để nó ở số ít, người gọi sẽ dễ dàng tự động hóa việc tạo mã cho thư viện khách của mình hơn.

Nếu bạn muốn giảm thiểu điều này, bạn có thể tự tạo SDK cho dịch vụ REST của mình. Hoặc, bạn chỉ có thể được ý kiến và giải quyết khiếu nại :)

— Chris McCall
nguồn