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 the enclosed entity be stored under the supplied Request-URI.
But what is the definition of 'enclosed entity'? It doesn't seem possible for me to send form data (like for HTTP POST request) over. What about sending representation of the entity via JSON/XML or in other serialization formats?
In short, how does one send a HTTP PUT request over to store/update info at a specific URI then?
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' }
});
not sure if this is the right answer, but I will probably just try
suppose after issuing a HTTP GET to http://example.org/api/foo/1, I get this
GET http://example.org/api/foo/1
Accept: application/json
Response:
{
"foo": "bar"
}
then to issue a put request
PUT http://example.org/api/foo/1
{
"foo": "baz"
}
as long as the application hosted at the endpoint understands the format I am sending.
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.
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.