CODEWITHSUNDEEP
restpostget
gnegi
gnegi

Reputation: 3

GET Vs POST in REST

According to Rest, we should use GET if we have to retrieve some data, and use POST if it's creating a resource.

But, if we have to take multiple parameters (more than 7-8), or list of UUIDs let's say, then shouldn't we use POST rather than GET?

To avoid:

  1. The complexity of the URL
  2. Future scope to incorporate any new field
  3. URL length which may limit us in future
  4. If we are not encoding our URL then we may risk of exposing params (least significant point though)

Thanks.

Upvotes: 0

Views: 152

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57387

GET Vs POST in REST

Use GET when the semantics of GET fit the use case; in other words, when you are trying to retrieve a copy of the latest representation of some resource.

Use POST when no other standardized method supports the semantics you need.

You can use POST for everything, but you give up the advantages of using more specialized methods -- the ability of general purpose components to do intelligent things because they understand the semantics of the request. For instance, GET has safe semantics, which means that a general purpose component knows that it can pre-fetch a representation of the resource before the user needs it, or automatically repeat a request if it doesn't get a response from the server.

What HTTP gives you is a extendable collections of refinements of the general purpose POST method, adding more specific constraints so that general purpose components can leverage the resulting properties.

The complexity of the URL

Complexity in the URL really isn't a big deal, as far as general purpose components are concerned a URL is just a opaque sequence of bytes that happens to abide by certain production rules. For the most part, the effective target-uri of a web request is treated as an atomic unit, so what might seem "complex to a human being doesn't bother the machines at all (for instance, take a look at the URL used when you submit a search from the google home page).

URL length which may limit us in future

We care a bit about URL length. RFC 3986 doesn't restrict the length of the URI, but some implementations of general purpose components will fail if the length is far outside the norm. So you probably don't want to include a url encoded copy of the unabridged works of Shakespeare in the query part of your request.

Future scope to incorporate any new field

Again, there's not a lot of difference here. Adding new optional elements to a URI template is really no different than adding new optional elements to a message template.

we may risk of exposing params

We also want to be careful about sensitive information - as far as the machines are concerned, the URI is an identifier; there's no particular reason to worry about a specific sequence of bytes. Which means that the URI may be exposed at rest (in a clients history, or list of bookmarks, in the servers access logs). Restricting sensitive information to the body of a message reduces the chance of the data escaping beyond its intended use.

Note that REST, and leveraging the different HTTP methods, isn't the only way to get useful work done. SOAP (and more recently gRPC) decided that a different collection of trade offs was better -- in effect, reducing HTTP to transport, rather than an application in itself.

According to Rest, we should ... use POST if it's creating a resource.

This is an incorrect interpretation of REST. It's a very common interpretation, but incorrect. The semantics of POST are defined by RFC 7231; it means that, and not something else.

The suggestion that POST should only be used for create is a misleading over simplification. The earliest references I've been able to find to it is a blog post by Paul Prescod in 2002; and of course it became very popular with the arrival of Ruby on Rails.

But recall: REST is the architectural style of the world wide web. HTML, the most common hypertext media type in use on the web, has native support for only two HTTP methods; GET, used to fetch resource representations from a server, and POST which does everything else.

Upvotes: 1

Mike Williams
Mike Williams

Reputation: 182

You should also use POST if you have sensitive data such as username and or password which are best encoded as form parameters (key value pairs)

Upvotes: 0

Related Questions