0

我正在为 Web 应用程序设计 REST API。

我在设计 API 时的原则是：

  • 使用客户端用例视角而不是数据模型视角。动机：从 DB 模式中抽象出来。
  • 每个斜线代表新的用例/操作。

可以说，在应用程序中，我们有用户、产品、位置、产品新闻。用例是用户从某个位置关注产品新闻。如果位置为空，则用户会关注每个位置的产品新闻。
产品和位置列表是众所周知的。

将用户添加为特定产品位置组合的关注者的正确方法是什么？

我最终得到以下网址：

/product/follow?product=<product_name>[&location=<location name>]

和名称在查询部分product，location因为将来扩展更灵活。

  • PUT的论据：当然，这个请求是幂等的——多次发送它不会像发送一次一样产生任何其他变化。
  • POST的参数：我们不指定设置资源的 URL。

就我个人而言，我更接近PUT，因为根据 API 的用例原则（我认为这是正确的），无能规则接缝是最对应的。

4

1 回答 1

1

首先确定资源。我想说的是

/products/<product_name>/followers

是所有关注的用户的列表product_name。您可以使用查询参数进行过滤：

/products/<product_name>/followers?location=<location_name>

product_name是来自的所有用户的列表location_name。

针对此类资源的GET请求会返回用户列表的表示形式（JSON、XML、...）。

POST 或者PUT

POST针对此类资源的请求会添加一个新用户。此类请求的请求正文POST包含详细信息。

POST /products/<product_name>/followers
Content-Type: application/json

{
  "user": "some user",
  "location: "some location"
}

服务器将响应：

201 Created
Location: /products/<product_name>/followers/some%20user

如果客户端知道 URI，它可以使用PUT：

PUT /products/<product_name>/followers/some%20user
Content-Type: application/json

{
  "location: "some location"
}

服务器将再次响应：

201 Created
Location: /products/<product_name>/followers/some%20user

概括

如果客户端能够准确知道 URI，则可以使用PUT. URL 只能被服务器知道，使用POST.

于 2013-09-05T07:16:11.150 回答