在一个请求中创建多个项的 RESTful 方式

我正在开发一个小型客户端服务器程序来收集订单。我想用一种“ REST (ful)方式”来做这件事。

我想做的是:

收集所有订单(产品和数量)并将完整的订单发送给服务器

目前,我看到了两种选择:

  1. 将每个订单行发送到服务器: POST qty 和 product _ id

我实际上不想这样做,因为我想限制对服务器的请求数,所以选项2:

  1. 收集所有订单并立即发送到服务器。

我应该如何实施备选方案2? 我有几个想法: 在 JSON 对象中包装所有订单行并将其发送到服务器或使用数组发布订单行。

实施方案2是一个好主意还是一个好做法,如果是的话,我应该怎么做。

什么是良好做法?

99170 次浏览

您不会希望为100个订单发送 HTTP 头。您也不希望生成任何超过必要数量的请求。

将一个 JSON 对象中的整个订单发送到服务器,发送到: server/order 或 server/order/new。 返回指向: server/order/order _ id 的内容

还可以考虑使用 创造 PUT 代替 POST

我觉得你的想法很有道理。实现取决于您的偏好。您可以使用 JSON 或者只使用参数(“ order _ lines []”数组) ,然后执行

POST /orders

因为您要在一个操作(顺序和它的行)中立即创建更多的资源,所以验证每一个资源并且只在所有资源都通过验证时保存它们是至关重要的,即。你应该用交易的方式来做。

尽管批量操作(例如批量创建)在许多系统中都是必不可少的,但它们并没有被 RESTful 架构风格正式地解决。

我发现按照您的建议发布一个集合基本上是可行的,但是当您需要报告响应这样一个请求的故障时,问题就出现了。当由于不同原因而发生多个故障时,或者当服务器不支持事务时,这些问题会更加严重。 我给您的建议是,如果没有性能问题,例如,当服务提供商位于 LAN (而非 WAN)上或数据相对较小时,向服务器发送100个 POST 请求是值得的。保持简单,从单独的请求开始,如果有性能问题,尝试进行优化。

我想最好在 单一连接中发送单独的请求。当然,你的网络服务器应该支持它

事实上,我最近一直在纠结这个问题,这就是我正在努力的方向。

如果添加多个资源的 POST 成功,返回一个200 OK (我考虑的是201,但是用户最终不会访问已创建的资源) ,同时返回一个页面,显示所有添加的资源,无论是以只读方式还是以可编辑方式。例如,用户可以使用仅包含单个文件输入的表单选择多个图像并将其 POST 到画廊。如果 POST 请求完全成功,用户将看到一组表单,用于创建的每个图像资源表示,这些表单允许用户指定关于每个图像资源的更多细节(名称、描述等)。

在创建一个或多个资源失败的情况下,POST 处理程序将中止所有处理,并将每个单独的错误消息附加到一个数组。然后,返回一个419冲突,并将用户路由到一个419冲突错误页面,该页面显示错误数组的内容,并返回到提交的表单。

Facebook 解释了如何做到这一点: https://developers.facebook.com/docs/graph-api/making-multiple-requests

简单的批处理请求

批处理 API 接受一组表示的逻辑 HTTP 请求 作为 JSON 数组-每个请求都有一个方法(对应于 HTTP 方法 GET/PUT/POST/DELETE 等) ,一个相对 _ url ( Graph.facebook.com 后的 URL) ,可选的头数组(相应的 以及一个可选的主体(用于 POST 和 PUT 请求) 批处理 API 返回一个逻辑 HTTP 响应数组,表示为 JSON 数组-每个响应都有一个状态码,一个可选的头 数组和一个可选的主体(它是一个 JSON 编码的字符串)。

我相信另一个正确的方法是创建另一个代表您的资源集合的资源。 例如,假设我们有一个类似于 /api/sheep/{id}的端点,我们可以 POST 到 /api/sheep来创建一个绵羊资源。

现在,如果我们想要支持批量创建,我们应该考虑在 /api/flock(如果没有更好的有意义的名称,则为 /api/<your-resource>-collection)处创建一个新的群资源。记住 资源不需要映射到您的数据库或应用程序模型。这是一个常见的误解。

资源是更高层次的表示,与您的数据无关。对资源进行操作可能会产生显著的副作用,比如向用户发送警报、更新其他相关数据、启动长期存在的进程等。例如,我们可以将文件系统甚至 unix ps命令映射为 REST API。

我认为可以有把握地假设,操作一个资源也可能意味着创建几个其他实体作为副作用。