Difference @GET @POST in REST architecture

Question

I am trying to understand the REST architecture, but I have a question.

I do not understand all the differences, between @POST and @GET...for me, I just see them in a technical point of view, where my framework (GWT-P) allows me to use various parameter (String, int, but not objects) with @GET and various parameters (including ONLY ONE object class) with @POST...

So, what kind of error (logical error, bad architecture etc...) could I create, if I am using a @POST instead of @GET ? Because, for example, if I want to retrieve data, it seems logical to use @GET, isn t it ? But, if I want to pass a lot of parameters usefull to retrieve theses data (eg: the day, the place, the user...), so technically, I have to use @POST...

So, @GET, @POST ? Is it strictly necessary to respect the logic that all 'retrieve operations' (I mean fetching data operations) should be @GET and never @POST ?

Thansk you,

Answer 1

First of all, REST is an architectural style, so it's protocol independent. Your question is more related to the proper usage of HTTP than REST.

If you need to pass parameters on your retrieval, you should send them in the query string, not in a POST. Keep in mind that the whole URI, including the query string, is an atomic identifier to your resource.

The problem with retrieving with POST is that this method is reserved for non-idempotent operations, that might have some side-effect on the server side. For instance, a POST is never cached, and a client can't resubmit a POST at will if the response is lost without first checking if the request actually succeeded.

Answer 2

Basically these HTTP methods are just semantics and their intended usage is just a guideline.

However, when handling these requests server-side remember, that web crawlers also use these methods, so, for example, making GET requests do anything besides just displaying data is unsafe and may produce some hard-to-track problems with your app.

A bit more on this. http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods

Answer 3

In the REST logic :

• GET => to get a resource (with an id)
• POST => to create a resource
• PUT => to update a resource (with an id)
• DELETE => to remove a resource (with an id)

It's rarely necessary to specify many parameters for a resource (otherwise, there's a problem in the software design).

Normally only an identifier as a parameter (or an identifier and a type of resource, a libel, ..., but no exceed the limit number of parameters in HTTP/GET).

Answer 4

If your publishing an API for this then I would use @GET methods, but if that is not the case use @POST by all means.

@POST gives you more options and dosn't have a limit on parameter query string length like @GET, the only negative is @POST is slower by a couple of milliseconds to create the request.

Answer 5

If you need to pass query information to a URI to specify exactly what resource you want don't use a POST. Use a GET with a query string.

For example

http://myapi.com/someresource?day=01012014&place=Dublin&user=JohnDoe

or if there is a meaningful hierarchy then build it into the URI itself

http://myapi.com/users/JohnDoe/locations/Dublin/telephones/01231414