具有大量输入数据的REST端点(GET) [英] REST endpoint (GET) with large input data
问题描述
我正在开发一个应用程序，其中我需要将对象列表传递给REST端点，该端点将进行一些计算并将结果返回给调用方.
I am developing an application where I need to pass a list of objects to a REST endpoint which will do some computation and return the result back to the caller.
问题更多是关于如何处理这种情况的哲学问题?
The question is more of a philosophical one as to how to deal with this situation?
在GET请求中传递巨大的有效负载是一个坏主意.同时，它并不是真正的POST/PUT请求，因为它没有修改服务器上的任何状态.
Passing a huge payload in the GET request is a bad idea. At the same time its not really a POST/PUT request as it is not modifying any state on the server.
以前有人遇到过吗?
推荐答案
问题更多是关于如何处理这种情况的哲学问题?
The question is more of a philosophical one as to how to deal with this situation?
网络哲学的一部分是，您不需要知道如何实现端点:预先计算答案的文档，即时计算的文档以及重定向到其他人的图片.
Part of the philosophy of the web is that you aren't supposed to need to know how an endpoint is implemented: a document with the answer pre-computed vs a calculation on the fly vs a redirect to somebody else.
因此，从纯粹的哲学角度来看，GET是正确的答案.
So from a purely philosophical point of view, GET is the correct answer.
GET不支持内容主体；您唯一的选择是将这种特定计算的结果表示为一种资源，换句话说，就是将您的数据放入URI.
GET doesn't support a content body; your only option there is to express the result of this particular calculation as a resource -- in other words, to get your data into the URI.
As a practical matter, you may run into arbitrary limits about how long the URI can be. So depending on the client (browser/library), that may be a problem.
PUT会很好；与POST相比，优点是PUT应该是幂等的，使用PUT可以通过统一接口在所需的丢失消息语义上进行通信.
PUT would be nice; the advantage over POST is that PUT is supposed to be idempotent, using PUT communicates across the uniform interface the lost message semantics you want.
不幸的是，PUT规范要求使用消息有效负载对目标资源进行替换.这实际上是关于文档传输的.就是说， RFC-7231 确实给了您一些摆动的空间. /p>
Unfortunately, the PUT specification calls for the replacement of the targeted resource with the message payload. It's really about document transfer. That said, RFC-7231 does give you some wiggle room.
当PUT表示与目标资源不一致时，源服务器应通过转换表示或更改资源配置来使其一致，或使用包含足够信息的适当错误消息进行响应，以解释为什么该表示不适合.
When a PUT representation is inconsistent with the target resource, the origin server SHOULD either make them consistent, by transforming the representation or changing the resource configuration, or respond with an appropriate error message containing sufficient information to explain why the representation is unsuitable.
因此，您可能会认为计算结果是表示形式的转换.
So you might be able to argue that the result of the calculation is a transformation of the representation.
PUT的使用与 RESTbucks 演示中，通过创建一个通过PUT方法在系统中创建订单，这将创建一个用于跟踪该订单状态的资源.
This use of PUT isn't really all that different from Jim Webber talks about. In the RESTbucks demo, you trigger side effects in the business domain by creating an order in the system via the PUT method, and this creates a resource that is used to track the state of that order.
在这种方法中，每个提交的计算都应具有唯一的标识符；您可以将输入内容放入该计算中，并返回结果201-已创建.从理论上讲，您可以在资源上支持GET，而不需要输入就返回结果，或者在资源上支持DELETE，这是对客户端已收到计算结果并且不需要服务器上的任何结果的一种确认.更长.
In that approach, each submitted calculation should have a unique identifier; you would PUT the inputs to that calculation, and it would return a 201 - Created, with the result. In theory you could then support GET on the resource, to return the result without requiring the inputs, or DELETE on the resource, as a sort of acknowledgment that the client has received the result of the calculation and will not need it on the server any longer.
或者不是-您实际上并不需要它，并且您当然不需要在每个资源上都支持所有http方法.
Or not - you don't actually need it, and you certainly aren't required to support all of the http methods on every resource.
如果这种方法不可接受(例如，如果您使用HTML作为媒体类型)，则POST是万能的方法.实际上，这并不适合您想要的内容.但是POST必须支持非幂等运算，这意味着统一接口将无法识别您的计算是幂等的.在幸福的道路上那没什么大不了的.
If that approach isn't acceptable (for instance, if you are using HTML as your media-type), the POST is your magic catch-all method. It's not actually a bad fit for what you want; but POST has to support non-idempotent operations, which means that the uniform interface won't recognize that your calculation is idempotent. That's not a big deal on the happy path.
这篇关于具有大量输入数据的REST端点(GET)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
