时间戳

首页 > 解决方案 > RESTful API 设计 - CRUD op。& 可选操作，都在一个请求中？

rest - RESTful API 设计 - CRUD op。& 可选操作，都在一个请求中？

问题描述

所以我正在创建一个 RESTful API 来管理数据库中的订单列表。有一个创建订单的选项，然后用户可以更新/编辑订单并最终调用POST /orders/{id}/send端点来发送订单。

现在，我们发现很多时候我们不需要编辑订单，可以直接创建和发送。由于在前端处理多个顺序请求有点混乱，我认为发出 Create & Update 请求是个好主意。这会违反 RESTful 模式吗？

如果它不是最好的方法（语义上）。它是否适合只使用具有可选sendDirectly查询或标头参数的 create-method？或者为此设置一个完全不同的端点是否更有意义？

你怎么看？

标签： restapi-designsemantics

解决方案

由于在前端处理多个顺序请求有点混乱，我认为发出 Create & Update 请求是个好主意。这会违反 RESTful 模式吗？

不，它不会。想想它在网络上的工作方式：有人导航到表单，填写信息，提交表单......然后后端对结果执行任何操作。

仅使用具有可选 sendDirectly 查询或标头参数的 create-method 是否合适？

资源标识符标识资源；查询是其中的一部分。因此，您不应该使用有效负载语义来重载查询。

处理这个问题的正常方法是在请求的有效负载的模式中有一个可选字段。在 Web 上，您可以通过表单中的隐藏输入控件通知客户端此字段。

有一个完全不同的端点会更有意义吗？

也许，但可能不是。您通常想要做的是识别将被请求更改的主要资源，并将该资源的标识符用作请求的目标 uri，以便标准缓存失效规则执行您想要的操作。

是的，这意味着您可能有多个表单，它们使用相同的方法向同一资源提交不同的信息。您设计有效负载，以便服务器可以区分它们，并在那里执行您的区分。

（注意：OpenAPI 3 似乎不支持记录这样的 API；“这是 Swagger 对 API 的看法的一个特点”。有时你必须选择妥协的地方。）

推荐阅读