4

我想知道，更新（！）项目的字段（状态）的更RESTFul，灵活和更好的方法是什么

/api/v1/items/:id?action=start 
/api/v1/items/:id/start 
/api/v1/items/:id/ + action in the body
/api/v1/items/:id/status/{active|stopped}

或物品

/api/v1/items?action=start 
/api/v1/items/start 
/api/v1/items/ + action in the body
/api/v1/items/status/{active|stopped}
4

3 回答 3

5

我更喜欢第三种 API 结构：

/api/v1/items/:id/ + action in the body

我的理由包括：

  • 根据Richardson 成熟度模型，URL 应该指向一个特定的资源或一组资源。您不想在 URL 中添加更新信息，因为它不符合有效端点的条件。
  • 您想将 PUT 用于影响资源的更新/替换操作。让 URL 选择资源并让正文定义您要更新的确切字段，否则任何其他逻辑。
  • 使用正文而不是查询字符串允许您插入任意大的信息（在一定限度内，但大于查询字符串），这些信息在逻辑上可能与操作配对（在您的情况下开始）。它还为将来扩展操作提供了更大的灵活性。
  • 您可能可以在 的响应中列出可以在端点上执行的相关操作/api/v1/items。这将是一个信息丰富的超媒体控件列表。同样，理查森成熟度模型提供了一个很好的例子。
于 2013-10-01T04:52:18.223 回答
1

作为替代方案，您可以实现 PATCH 方法。它将为您提供更新选择性字段的可能性。PATCH 的唯一问题是它是未知的，因为 RFC 还很年轻。实际实现取决于您的服务器和客户端库和框架。

当您不想使用 PATCH 时，唯一的选择是实现覆盖的 POST 并定义更新机制。例如，您可以说：每个字段！= null 将覆盖资源字段值。

于 2013-11-12T14:52:20.833 回答
0

让我们重新表述这个问题：我如何更改资源的少数属性。（状态只是另一个属性）

回答：

识别资源。

在正文中使用 POST（因为请求是非幂等的）供应，因为将来您可能需要更改更多属性，而不仅仅是该资源的状态。

POST /api/v1/items/:id + 正文中的操作

仅使用POST方法。

原因： 当它更改完整的属性集而不是一个或部分属性时，应该使用Put 。

请让我们继续前进。我们不需要对 HTTP 中的每个状态更改都使用 PUT。REST 从未说过我们应该这样做。可以使用 POST - roy t fielding

于 2013-10-01T06:00:44.597 回答