我正在开发一个应用程序，我需要将一个对象列表传递给REST端点，该端点将进行一些计算并将结果返回给调用者。
问题更多的是关于如何处理这种情况的哲学问题？
在GET请求中传递巨大的有效负载是个坏主意。同时它不是真正的POST / PUT请求，因为它没有修改服务器上的任何状态。
以前有人遇到过这个问题吗？
答案 0 :(得分：3)
问题更多的是关于如何处理这种情况的哲学问题？
网络的一部分理念是，您不需要知道端点是如何实现的：具有预先计算的答案与动态计算与重定向到其他人的文档。
因此，从纯粹的哲学观点来看，GET是正确答案。
GET不支持内容正文;您唯一的选择是将此特定计算的结果表示为资源 - 换句话说，将数据输入URI。
实际上，您可能会遇到arbitrary limits关于URI的长度。因此，根据客户端（浏览器/库），这可能是一个问题。
PUT会很好;优于POST的优点是PUT应该是幂等的，使用PUT通过统一接口与您想要的丢失消息语义进行通信。
不幸的是，PUT规范要求使用消息有效负载对目标资源进行替换。这真的是关于文件传输。也就是说，RFC-7231确实给你一些摆动空间。
当PUT表示与目标资源不一致时，源服务器应该通过转换表示或更改资源配置来使它们保持一致，或者使用包含足够信息的相应错误消息进行响应，以解释表示不适合的原因。
所以你可能会认为计算的结果是表示的转换。
这种PUT的使用与Jim Webber谈论并没有什么不同。在RESTbucks演示中，您可以通过PUT方法在系统中创建订单来触发业务域中的副作用，这会创建一个用于跟踪该订单状态的资源。
在该方法中，每个提交的计算应具有唯一标识符;你会把输入输入到那个计算中，它会返回一个201 - Created，结果。理论上，您可以在资源上支持GET，在不需要输入的情况下返回结果，或者在资源上删除，作为一种确认，即客户端已经收到计算结果，并且在服务器上不需要它更长的时间。
或者不是 - 您实际上并不需要它，并且您当然不需要支持所有资源上的所有http方法。
如果这种方法不可接受（例如，如果您使用HTML作为媒体类型），那么POST就是您的神奇抓取方法。它实际上并不适合你想要的东西;但POST必须支持非幂等操作，这意味着统一接口将无法识别您的计算是幂等的。这对幸福的道路来说并不是什么大不了的事。