我正在开发一个小型客户端服务器程序来收集订单。我想以“REST（ful）方式”这样做。
我想做的是：
收集所有订单（产品和数量）并将完整订单发送到服务器
目前我看到两个选项：
我实际上不想这样做，因为我想限制对服务器的请求数量，所以选项2：
我应该如何实施选项2？我有几个想法是： 将所有订单行换行并放入服务器或使用数组发布订单行。
实施选项2是一个好主意还是一个好习惯，如果是，我应该怎么做。
什么是好习惯？
答案 0 :(得分：60)
我认为另一种正确的方法是创建另一个代表您的资源集合的资源。
例如，假设我们有一个类似/api/sheep/{id}的端点，我们可以POST到/api/sheep来创建一个绵羊资源。
现在，如果我们想要支持批量创建，我们应该在/api/flock（或/api/<your-resource>-collection处考虑新的群资源，如果您缺少更有意义的名称）。请注意，资源不需要映射到您的数据库或应用模型。这是一种常见的误解。
资源是更高级别的表示，与您的数据无关。在资源上操作可能会产生严重的副作用，例如向用户发出警报，更新其他相关数据，启动长期过程等。例如，我们可以映射文件系统甚至unix ps命令作为REST API。
我认为可以安全地假设操作资源也可能意味着创建其他几个实体作为副作用。
答案 1 :(得分：41)
虽然批量操作（例如批量创建）在许多系统中都是必不可少的，但RESTful架构风格并没有正式解决这些问题。
我发现按照您的建议发布集合基本上可行，但是当您需要报告响应此类请求的失败时会出现问题。当因不同原因发生多次故障或服务器不支持事务时，此类问题会更严重。 我的建议是，如果没有性能问题，例如当服务提供商在LAN（而不是WAN）上或数据相对较小时，向服务器发送100个POST请求是值得的。保持简单，从单独的请求开始，如果遇到性能问题，请尝试优化。
答案 2 :(得分：10)
Facebook解释了如何执行此操作：https://developers.facebook.com/docs/graph-api/making-multiple-requests
简单批量请求
批处理API接收表示的逻辑HTTP请求数组 作为JSON数组 - 每个请求都有一个方法（对应于HTTP） 方法GET / PUT / POST / DELETE等），一个relative_url（部分） graph.facebook.com之后的URL，可选的头文件数组（对应 到HTTP标头）和一个可选的主体（用于POST和PUT请求）。该 Batch API返回表示为的逻辑HTTP响应数组 JSON数组 - 每个响应都有一个状态代码，一个可选的标头 数组和一个可选的主体（这是一个JSON编码的字符串）。
答案 3 :(得分：8)
你的想法似乎对我有用。实施是您的偏好问题。您可以使用JSON或仅使用参数（“order_lines []”数组）并执行
POST /orders
由于您要在单个操作（顺序及其行）中一次创建更多资源，因此只有在所有这些资源都通过验证时才能验证它们中的每一个并保存它们，即。你应该在交易中做到这一点。
答案 4 :(得分：6)
我想最好在single connection内发送单独的请求。当然，您的Web服务器应该支持它
答案 5 :(得分：5)
我最近一直在努力解决这个问题，而这正是我正在努力的目标。
如果添加多个资源的POST成功，则返回200 OK（我考虑的是201，但用户最终没有登陆已创建的资源）以及显示已添加的所有资源的页面，以只读或可编辑的方式。例如，用户能够使用仅包括单个文件输入的表单来选择多个图像并将其POST到图库。如果POST请求完全成功，则向用户显示创建的每个图像资源表示的一组表单，这些表单允许他们指定关于每个（名称，描述等）的更多细节。
如果无法创建一个或多个资源，POST处理程序将中止所有处理并将每个错误消息附加到数组。然后，返回419冲突，并将用户路由到419冲突错误页面，该页面显示错误数组的内容，以及返回到已提交表单的方式。
答案 6 :(得分：0)
您不希望发送100个订单行的HTTP标头。您既不想生成超出必要的请求。
将整个订单在一个JSON对象中发送到服务器，发送到：server / order或server / order / new。 返回指向的内容：server / order / order_id
另外考虑使用 CREATE PUT而不是POST