The fundamental difference between POST and PUT requests is reflected in the significance of Request-URI. The URI in a POST request identifies the resource that will handle the attached entity. The resource can be a data acceptance process, a gateway for another protocol, or a separate entity that accepts annotations. In contrast, the URI in the PUT request identifies the entity attached to the request - the user agent knows which URI is intended and the server MUST NOT try to apply the request to another resource. If the server wants the request to be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision about redirecting the request or not.

That is, the PUT should be used in more specific situations where you want to send information and do nothing but store it in some way. The POST is more general, it assumes that the information is only part of the process that will be carried out. POST allows you to have any side effects, or at least this is expected to occur. It is hoped that the PUT has no unknown, or undesirable. It is idempotente (homage to bfavaretto).

In some scenarios you can think of more specific semantics (REST, I'm talking about you) for each verb. But essentially they work in an analogous way. In CRUD scenarios, PUT is usually used to update something and POST to create (or do other operations that do not fit the basic CRUD), just like GET is used to read, and DELETE obviously to delete.

Of course the recommendation is to follow what the RFC says. But it is almost safe to say that it does not matter much. In the future it might be that they would impose some restriction or have some effect based on what the RFC says. And then anything that did not follow her would have problems. "Legally" could do this. But since no one follows the RFC, it would break so much, that this will never be changed.

In doubt, everyone uses the POST that is best known and should always work. I have my doubts whether it should not be the other way around. But the damage is done already.

Although I do not respond directly, I strongly advise reading the bfavaretto response . You have another useful , too.

Update 1

When requesting a resource, such as a query, it is usual to use information passing using get .

URI: http://servidor/recurso/consulta/{id}
GET: {id}

However, using the get verb generates URI's for each value entered, exposing the information and making cache optimization impossible if the request response is the same. This way we have the verb post to load the information inside the package without being in URI .

URI: http://servidor/recurso/consulta
POST: {id}

The verbs put and delete are loaded with semantics. When creating or transferring a resource the most appropriate verb is put . To exclude a resource the most appropriate verb is delete .

URI: http://servidor/recurso/novo
PUT: {nome,cidade,estado}

URI: http://servidor/recurso/excluir/{id}
DELETE

PUT places a file or resource in a specific URI . If a file or resource already exists in this URI , the PUT method will overwrite the file (or resource). If there is no file or resource there, the PUT method creates one.

POST sends data to a specific URI to handle the request. The web server, at this point can determine what to do with the data in the context of the specified resource.

source >