REST endpoint (GET) with large input data

Question

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?

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.

Has anyone faced this before?

Answer 1

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.

So from a purely philosophical point of view, GET is the correct answer.

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 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.

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.

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.

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.

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.

Or not - you don't actually need it, and you certainly aren't required to support all of the http methods on every resource.

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.