rest api 子资源答案

【问题标题】：rest api sub resourcerest api 子资源
【发布时间】：2014-11-21 02:03:52
【问题描述】：

我问了一个类似的问题，但可能太复杂了 - https://stackoverflow.com/questions/26900550/rest-api-design-for-performing-different-actions-on-an-underlying-object?noredirect=1#comment42354797_26900550

我的系统的业务规则如下：

用户可以使用客户和站点地址创建/更新作业（每个作业的地址更改）。新报价会自动创建一个 status = new 的新报价（每个工作仅 1 个报价）
用户可以更新报价详情 - 总计、加价等。
有几种报价状态（新、已发送、暂停、已赢、已丢失）。每个状态都需要附有该状态独有的数据，例如'sent' 需要发送日期，'won' 和 'lost' 需要决定日期。当作业被标记为中标时，该作业需要一个或多个采购订单记录，因此我希望收到一组采购订单记录以及 status=won。

我正在尝试使用名词和子资源作为最佳实践，并不一定要让其余的 api 与我的数据库模型匹配，但它是新的和可怕的。

jobs (get, post)
jobs/{id} (get, put)
jobs/{id}/status (post, delete)
jobs/{id}/quote  (post, put, delete)
jobs/{id}/quote/decision (post, delete)

最后一个端点是报价状态将更改为赢/输等的位置。删除功能是为了以防作业被意外标记为赢/输并需要返回以发送。

任何人都可以就这是否是构建 api 的好方法还是我做得过火提供建议或见解？

【问题讨论】：

标签： api rest

【解决方案1】：

PUT 总是需要一个资源的完整表示，如果你想做部分更新，你需要 PATCH。

如果您已经知道资源的 URI，例如 jobs/{id}/quote，则使用 PUT 或 PATCH 进行创建，而不是 POST。 POST 是用于在集合中创建项目资源，而不是用于创建子资源。

请注意，您正在定义链接，例如GET jobs、POST jobs 等等...您为 GET 提供的响应应该包含这些链接，以便客户端可以使用它们。您需要将元数据添加到这些链接，例如link relations 或来自related vocab 的RDF 属性等......这样客户端就会知道链接的作用。 URI 中的名词只是为了检查我们是否真的在谈论资源而不是操作，客户端与 URI 结构无关。

我建议你首先阅读REST constraints。之后，您应该阅读 HTTP 标准的基础知识。如果您更喜欢 RDF，您还应该找到合适的超媒体格式，例如 HAL+JSON 或 JSONLD+Hydra。之后你就可以工作了。

【讨论】：