What is the HTTP PUT request method and how to use it?
The HTTP PUT method is used to update or replace an existing resource on the server, while the POST method is used to add a resource on the server. When you make an HTTP PUT request, and the Request-URI points to an existing resource, the server MUST completely replace that resource with the data enclosed in the body of the PUT request. If the Request-URI does not point to an existing resource, the origin server MAY add a new resource with that URI. To partially replace an existing resource, use the HTTP PATCH request method. In this HTTP PUT Request Example, we send an HTTP PUT request to the ReqBin echo URL. Click Send to make the PUT request online and see the result.
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.
HTTP/1.1 200 OK
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
Browser BACK button/Reload
Data will be re-submitted (the browser should alert the user that the data are about to be re-submitted)
Can be bookmarked
Cannot be bookmarked
Can be cached
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)
Restrictions on data type
Only ASCII characters allowed
No restrictions. Binary data is also allowed
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!
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.