The HTTP PUT method is used to update an existing resource on the server, while the POST method creates or adds a resource on the server. The HTTP PUT method is defined as idempotent, which means that multiple identical PUT requests should have the same effect as a single request. The HTTP PUT method is used to update an existing resource on the server, while the POST method creates or adds a resource on the server. Unlike GET and HEAD requests, the HTTP PUT request may change the server state. The HTTP PUT method is defined as idempotent, which means that multiple identical HTTP PUT requests should have the same effect as a single request.
You can send data to the server in the body of the HTTP PUT request. The type and size of data are not limited. But you must specify the data type in the Content-Type header and the data size in the Content-Length header fields. You can also post data to the server using URL parameters with a PUT request. In this case, you are limited to the maximum size of the URL, which is about 2000 characters (depends on the browser).
HTTP PUT Example
The following example demonstrates making an HTTP PUT request to the server. In this example, the 'Content-Type: application/json' request header indicates the media type of the resource, and the 'Content-Length: 85' request header indicates the size of the data in the HTTP PUT request body.
And the server response:
HTTP PUT Response Codes
If a new resource is created, the origin server MUST inform the client with a 201 (Created) status code. If an existing resource has been modified, status codes 200 (OK) or 204 (No Content) SHOULD be returned to indicate to the client that the request was successful. If the resource cannot be created or modified, an appropriate error code MUST be returned that reflects the nature of the problem (usually 500x).
Some notes on HTTP PUT requests:
- PUT requests are never cached
- PUT requests do not remain in the browser history
- PUT requests cannot be bookmarked
HTTP PUT vs GET
GET | PUT | |
Browser BACK button/Reload | Harmless | Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted) |
Bookmarked | Can be bookmarked | Cannot be bookmarked |
Cached | Can be cached | Not cached |
History | Parameters remain in browser history | Parameters are not saved in browser history |
Restrictions on data length | Yes, when sending data, the GET method adds the data to the URL; and the length of a URL is limited (maximum URL length is 2048 characters) | No restrictions |
Security | GET is less secure compared to PUT because data sent is part of the URL Never use GET when sending passwords or other sensitive information! | |
Visibility | Data is visible to everyone in the URL | Data is not displayed in the URL |
HTTP PUT vs POST
The fundamental difference between the HTTP PUT and POST requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. In contrast; the URI in a PUT request identifies the entity enclosed with the request. Practically speaking, POST is used to append a resource to an existing collection, while PUT is used to update an existing resource.