CODEWITHSUNDEEP
web-serviceshttprest
Gleeb
Gleeb

Reputation: 11289

Alternative approach to sending a lot of parameter data on GET

I am creating a REST-API and am encountering a problem where the client needs to get a calculation based on a lot of different parameters.

This GET operation might not be a part of any Save or Update operations (before the GET or after), and can happen in a stateless manner.

Due to this the GET URL can be very long (and even exceed the maximum allowed by the browser).

I have looked in other posts here in SO and elsewhere and it is discouraged to use a body in GET requests. But whats most important about all these posts is that none of them give an alternative to this problem they just state that something is flawed in the design ETC...ETC...

Well nothing is wrong with the design here. its a stateless calculation built on a lot of parameters.

I would like some alternatives. Thank you.

Upvotes: 2

Views: 1198

Answers (3)

Julian Reschke
Julian Reschke

Reputation: 42017

So you want a safe HTTP method that accepts a payload. Have a look at http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-14.html - both SEARCH and REPORT are theoretical candidates, if you can live with the WebDAV baggage they come with.

An alternative would be to start work on either generalizing these, or defining something new (but don't forget that definitions of new HTTP methods need IETF review, see http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#considerations.for.new.methods.

Upvotes: 0

CodeCaster
CodeCaster

Reputation: 151586

nothing is wrong with the design here

There is. From Wiki:

An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., a URI in HTTP).

Your calculation parameters have nothing to do with the underlying resource identified by the URL you make the request to. You're not requesting an existing resource (as that's what GET is for, depending on how you're willing to interpret REST), but some calculations will be done based on some input. This is a Remote Procedure Call, not a REST call.

You can change your approach by modeling a Calculation, so you send a POST /Calculations/ request with all your parameters.

There's no requirement for a POST call to change server state (i.e. store the results):

httpbis-draft, POST (which is somewhat better worded and updated than RFC 2616):

  • The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
  • POST is used for (among others): providing a block of data, such as the fields entered into an HTML form, to a data-handling process;

So you can just return the calculation results along with a 200, or you can store them and return a 200, 201 or 204, containing or pointing to the calculation results, so you can retrieve them later, using GET /Calculations/$id.

Upvotes: 1

Aaron Digulla
Aaron Digulla

Reputation: 328564

As far as I can tell, the only solution you have left is to break the rules of REST and use a POST request. POST can have an arbitrary number of arguments, but it's meant for a "modification" operation in REST.

Like everything in software, the rules are there to help you avoid mistakes. But if the rules prevent you from solving your problems, you need to modify them a little bit (or modify them for a well defined part of your code).

Just make sure that everyone understands how you changed the rules, where the new rules apply (and where they don't). Otherwise, the next guy will "fix" your "broken" code with his simple test cases.

Upvotes: 0

Related Questions