具有大量输入数据的 REST 端点 (GET)答案

【问题标题】：REST endpoint (GET) with large input data具有大量输入数据的 REST 端点 (GET)
【发布时间】：2016-10-22 20:49:23
【问题描述】：

我正在开发一个应用程序，我需要将对象列表传递给 REST 端点，该端点将进行一些计算并将结果返回给调用者。

这个问题更像是一个哲学问题，如何处理这种情况？

在 GET 请求中传递大量有效负载是一个坏主意。同时它不是真正的 POST/PUT 请求，因为它没有修改服务器上的任何状态。

以前有人遇到过这种情况吗？

【问题讨论】：

你能举个例子吗？通过将对象列表作为请求负载传递，您违反了 REST 而不是 HTTP。此外，如果服务器需要进行大量计算，它可能根本不是 REST，因为没有涉及特定资源，或者您的资源标识在语义上是错误的。
当然。所以我传入 List ，其中 MyObject 将包含几个字段（比如 FieldOne 和 FieldTwo）。服务器上还有其他数据也将用于计算。让我们将其称为 FieldWithServer。由于服务器不知道 MyObject，我必须通过它。获取 List 后，它将基于 FieldOne、FieldTwo 和 FieldWithServer 进行计算。如果我不够清楚，请告诉我。
GET 会返回什么？
它将返回一个不超过 4 个属性的对象。

标签： rest get

【解决方案1】：

这个问题更像是一个哲学问题，如何处理这种情况？

Web 的部分理念是，您不需要知道端点是如何实现的：带有预先计算答案的文档、即时计算以及重定向到其他人的文档。

所以从纯哲学的角度来看，GET 是正确的答案。

GET 不支持内容主体；您唯一的选择是将这个特定计算的结果表示为资源 - 换句话说，将您的数据放入 URI。

实际上，您可能会遇到arbitrary limits 关于 URI 可以有多长的问题。因此，根据客户端（浏览器/库），这可能是个问题。

PUT 会很好；与 POST 相比的优势在于 PUT 应该是幂等的，使用 PUT 通过统一接口传达您想要的丢失消息语义。

不幸的是，PUT 规范要求用消息负载替换目标资源。这真的是关于文件传输。也就是说，RFC-7231 确实给了你一些回旋余地。

当 PUT 表示与目标资源不一致时，源服务器应该通过转换表示或更改资源配置使它们保持一致，或者以包含足够信息的适当错误消息进行响应，以解释表示不合适的原因.

因此您可能会争辩说计算的结果是表示的转换。

PUT 的这种用法与Jim Webber 所谈论的并没有什么不同。在RESTbucks 演示中，您通过 PUT 方法在系统中创建订单来触发业务领域的副作用，这会创建用于跟踪该订单状态的资源。

在这种方法中，每个提交的计算都应该有一个唯一的标识符；您可以将输入输入到该计算中，它会返回 201 - Created 和结果。理论上，您可以在资源上支持 GET，在不需要输入的情况下返回结果，或者在资源上支持 DELETE，作为客户端已收到计算结果并且在服务器上不需要它的一种确认更长。

或者不需要 - 你实际上并不需要它，而且你当然不需要支持每个资源上的所有 http 方法。

如果这种方法不可接受（例如，如果您使用 HTML 作为媒体类型），那么 POST 就是您的神奇万能方法。它实际上并不适合您想要的东西。但是 POST 必须支持非幂等操作，这意味着统一接口不会识别您的计算是幂等的。在幸福的道路上，这没什么大不了的。

【讨论】：