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