I know HTTP PUT is an idempotent request that store something at a specific URI, according to the definition (quoted from the rfc)
The PUT method requests that t
If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.
So a HTTP PUT request is often issued to replace the currently stored resource at a given URI. For example, there's a book stored at https://example.org/book/1 where the data can be representated in JSON as follows,
$ curl --request GET https://example.org/book/1
{
"title": "Stackoverflow Compilation Book 1",
"year": 2019
}
Suppose someone wants to fix the year
field because the fictional book was published last year (2018), he/she would have to send the COMPLETE updated book info over through a HTTP PUT request.
$ curl --request PUT
--header "Content-Type: application/json"
--data '{"title": "Stackoverflow Compilation Book 1", "year": 2018}'
Notice the change in year
attribute.
Considering a HTTP PUT request is essentially a replace operation, one can also replace the book represented by the URI to something else. For instance,
$ curl --request PUT
--header "Content-Type: application/json"
--data '{"title": "Some random book that nobody publishes", "year": 2019}'
The attached data can be in any format (usually also specified in the request header Content-Type
, as shown above), as long as it is supported, usually reported by Accept
response header (which denotes what kind of data type the application is willing to deal with). Further validation would be handled by the application code to determine whether the submitted data is valid.
The enclosed entity is the payload data contained in the HTTP message body (after any transfer encodings have been removed.) If you're having trouble sending the message body then it could be that you've forgotten to include a Content-Length header - that's one of two ways to indicate that the HTTP message has a body.
PUT is the same as POST except for this semantic difference: With POST the URI identifies a resource that will handle the entity, such as a servlet. With PUT the URI identifies the entity itself, for example a file that will be created/replaced with the contents of the entity body.
In REST you have:
GET - retrieve resource
POST - create new resource
PUT - update existing resource
DELETE - delete resource
So the PUT verb is used to update an existing resource on the server. Depending on the client there are various ways of sending a PUT request. For example with jquery AJAX:
$.ajax({
type: 'PUT',
url: '/products/123',
data: { name: 'new product name' }
});
You send a HTTP PUT where the body is the 'enclosed entity' that you wish to store under the requested URL. Very similar to POST, it is only the semantics as specified in the RFC, that differ.