休息api子资源

Question

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

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

1. 用户可以使用客户和站点地址创建/更新作业（每个作业的地址更改）。新报价会自动创建一个状态=新的报价（仅限每个作业1个报价）
2. 用户可以更新报价详细信息 - 总计，标记等。
3. 有几种报价状态（新的，已发送的，暂停的，赢的，丢失的）。每个状态都需要附带状态特有的数据，例如＆＃39;发送＆＃39;要求发送日期，赢得＆＃39;并且＆＃39;失去了＆＃39;需要一个决定日期。当作业被标记为获胜时，作业需要一个或多个采购订单记录，因此我希望收到一系列采购订单记录以及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的好方法还是我过度使用它？

Answer 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标准的基础知识。您应该找到适当的超媒体格式，例如HAL + JSON或JSONLD + Hydra如果您更喜欢RDF。之后你可以工作。