大输入数据的REST端点（GET）

Question

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

问题更多地是关于如何处理这种情况的哲学问题？

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

有没有人遇到过这个？

Answer 1

这个问题更多地是关于如何处理这种情况的哲学问题？网络的理念

的是，你不应该需要知道端点是如何实现的：与答案文档预先计算VS上飞VS重定向到其他人的计算。

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

GET不支持内容正文;您唯一的选择就是将此特定计算的结果表示为资源 - 换句话说，将您的数据存入URI。

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

PUT会很好;与POST相比，它的优势在于PUT应该是幂等的，使用PUT通过统一接口传递所需的丢失消息语义。

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

当PUT表示是与目标资源不一致，源服务器应该或者使它们一致，通过变换表示或改变资源的配置，或用含有足够的信息以适当的错误消息来响应解释为什么表示是不合适的。

所以你可能会争辩说，计算的结果是表示的转换。

这种使用PUT并非真正与Jim Webber谈论的不同。在RESTbucks演示中，您可以通过PUT方法在系统中创建订单来触发业务域中的副作用，并创建一个用于跟踪订单状态的资源。

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

不是 - 你并不需要它，你当然也不需要在每个资源上都支持所有的http方法。

如果这种方法是不可接受的（例如，如果您使用HTML作为您的媒体类型），POST是您不可或缺的方法。它并不适合你想要的东西;但POST必须支持非幂等操作，这意味着统一接口不会识别您的计算是幂等的。在快乐的道路上这不是什么大不了的事情。