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

我正在开发一个小型客户端服务器程序来收集订单。我想以“ REST（有效）方式”执行此操作。

我想做的是：

收集所有订单行（产品和数量）并将完整的订单发送到服务器

目前，我看到执行此操作的两个选项：

1. 将每个订单行发送到服务器：POST数量和product_id

我实际上不想这样做，因为我想限制对服务器的请求数，因此选项2：

2. 收集所有订单行并将它们立即发送到服务器。

我应该如何实施选项2？我有两个想法：将所有订单行包装在JSON对象中，然后将其发送到服务器或使用数组发布订单行。

实施选项2是个好主意还是好的做法，如果是的话，我应该怎么做。

什么是好习惯？

我相信解决此问题的另一种正确方法是创建另一个资源，该资源代表您的资源集合。例如，假设我们有一个类似的端点/api/sheep/{id}，并且可以通过POST /api/sheep创建一个羊资源。

现在，如果我们要支持批量创建，则应该考虑使用新的羊群资源/api/flock（或者/api/<your-resource>-collection如果您缺少更好的有意义的名称）。请记住，资源不需要映射到您的数据库或应用程序模型。这是一个普遍的误解。

资源是更高级别的表示，与您的数据无关。对资源进行操作会产生严重的副作用，例如向用户发出警报，更新其他相关数据，启动寿命长的进程等。例如，我们可以将文件系统甚至unix ps命令映射为REST API。

我认为可以安全地假设运行资源也可能意味着要创建其他几个实体。

尽管在许多系统中批量操作（例如批创建）是必不可少的，但是RESTful体系结构样式并未正式解决它们。

我发现按照您的建议发布集合基本上可以正常工作，但是当您需要响应此类请求报告失败时会出现问题。当由于不同原因而导致多次失败或服务器不支持事务时，此类问题会更​​加严重。我的建议是，如果没有性能问题，例如当服务提供商位于LAN（而非WAN）上或数据相对较小时，向服务器发送100个POST请求是值得的。保持简单，从单独的请求开始，如果您遇到性能问题，请尝试进行优化。

Facebook解释了如何执行此操作：https : //developers.facebook.com/docs/graph-api/making-multiple-requests

简单的批处理请求

批处理API接收一个表示为JSON数组的逻辑HTTP请求的数组-每个请求都有一个方法（对应于HTTP方法GET / PUT / POST / DELETE等），relative_url（在graph.facebook之后的URL部分）。 com），可选的标头数组（对应于HTTP标头）和可选的正文（用于POST和PUT请求）。Batch API返回表示为JSON数组的逻辑HTTP响应数组-每个响应都有一个状态码，一个可选的标头数组和一个可选的主体（这是JSON编码的字符串）。

您的想法对我来说似乎是正确的。具体实施取决于您的偏好。您可以为此使用JSON或仅使用参数（“ order_lines []”数组），然后执行

POST /orders

由于您将要在一个操作（订单及其行）中一次创建更多资源，因此至关重要的是验证每个资源并仅在所有资源都通过验证后才保存它们，即。您应该在交易中进行。

我猜最好在单个连接中发送单独的请求。当然，您的网络服务器应该支持它

实际上，我最近一直在为此努力，这就是我正在努力的方向。

如果添加多个资源的POST成功，则返回200 OK（我正在考虑使用201，但是用户最终不会落在已创建的资源上）以及显示已添加的所有资源的页面，无论是已读还是已读-或可编辑的方式。例如，用户能够使用仅包含一个文件输入的表单选择多个图像并将其发布到画廊。如果POST请求完全成功，则会为用户显示一组针对创建的每个图像资源表示形式的表单，这些表单使他们可以指定有关每个表单的更多详细信息（名称，描述等）。

如果无法创建一个或多个资源，则POST处理程序将中止所有处理，并将每个错误消息附加到数组中。然后，返回419冲突，并将用户路由到419冲突错误页面，该页面显示错误数组的内容以及返回提交表单的方式。

您将不希望发送100个订单行的HTTP标头。您都不希望生成超出必要数量的请求。

将整个订单以一个JSON对象的形式发送到服务器：服务器/订单或服务器/订单/新。返回指向的内容：server / order / order_id

还可以考虑使用CREATE PUT而不是POST