http - REST URL 结构建议

Question

我正在尝试为我正在处理的网站的心愿单部分确定一个 Restful url 结构。这是一个非常简单的模型，一个用户可以有很多愿望 list ，每个愿望 list 可以包含很多产品。

目前我有明显的 CRUD URL 来操纵愿望 list 本身:

GET account/wishlists.json
GET account/wishlists/{id}.json
POST account/wishlists.json?name=My%20Wishlist
POST account/wishlists/{id}.json?name=My%20New%20Name
DELETE account/wishlists/{id}.json

但是，我不认为我知道如何构建将产品添加/删除到心愿单的 URL :(

这是我目前的选择:

1) 将产品添加为 URL 的一部分并使用 HTTP 动词定义我的操作

POST account/wishlist/{id}/product/{product_id}.json
DELETE account/wishlist/{id}/product/{product_id}.json

或

2) 将操作作为 URL 的一部分，并将产品 ID 作为负载的一部分

POST account/wishlist/{id}/add.json?product_id={product_id}
POST account/wishlist/{id}/remove.json?product_id={product_id}

(1) 很干净，据我所知它非常 RESTful，但不允许轻松添加多个产品等。

我也有点担心使用 DELETE 动词 - 我没有删除产品或心愿单，我只是从另一个中删除一个。

(2) 更明确但偏离了 REST - 我不会只是指 url 中的资源，我会指对该资源的操作 :(

关于以上哪项更正确的任何建议都将非常有帮助! (如果有第三种选择比我的更好，请随时纠正我!)

Answer 1

(1) 是 REST 的唯一有效方法，使用 HTTP 动词进行操作。

(2) 将方法名称编码到 URI 中，这更像 RPC，当然不是 RESTful。

关于第一种方法的缺点:

• DELETE 动词很好，因为您的资源是愿望 list 中的项目，而不是项目本身。
• 您可以支持批量请求。例如，您可能希望允许将项目列表POST 到愿望 list 资源，从而导致多次添加。

PS:优先使用 HTTP 内容协商(Accept 和 Content-Type header )，而不是 URI 中编码的表示格式。