What is the HTTP PUT Request Method?

The HTTP PUT method is designed to update or replace an existing resource on the server. If the resource specified by the URI already exists, the server completely replaces it with the data provided in the body of the PUT request. However, if the specified URI does not exist, the server may create a new resource using that URI.

For partial updates, the HTTP PATCH method is recommended instead of PUT. This method is frequently used in REST APIs to modify data efficiently.

How HTTP PUT Differs from POST

• PUT: Updates or replaces a resource at a specific URI.
• POST: Adds a new resource to the server.
• PUT requests are idempotent, meaning that sending the same request multiple times produces the same result as sending it once. In contrast, POST requests are not idempotent and can result in the creation of duplicate resources if sent multiple times.

Sending an HTTP PUT Request

When making a PUT request, data is sent to the server in the body of the HTTP request. While there are no limitations on data type or size, you must specify:

• Content-Type Header: Indicates the format of the data (e.g., application/json).
• Content-Length Header: Specifies the size of the data being sent.

Although it’s possible to include data in the URL using query parameters, this approach is limited to approximately 2000 characters, depending on the browser.

Example: HTTP PUT Request

The example below demonstrates an HTTP PUT request where JSON data is sent to update a resource on the server:

PUT /api/resource/1 HTTP/1.1  
Host: example.com  
Content-Type: application/json  
Content-Length: 85  

{  
  "id": 1,  
  "name": "Updated Resource",  
  "status": "Active"  
}

HTTP PUT Response Codes

The server returns specific status codes based on the result of the PUT request:

• 201 (Created): A new resource was successfully created.
• 200 (OK) or 204 (No Content): An existing resource was successfully updated.
• 4xx/5xx: Error codes indicating a failure, such as unauthorized access or server issues.

Key Characteristics of HTTP PUT Requests

• Not Cached: PUT requests are never stored in browser caches.
• No History: Parameters in PUT requests are not saved in browser history.
• Cannot Be Bookmarked: Unlike GET requests, PUT requests cannot be bookmarked.
• Changes Server State: PUT can modify or create resources on the server.

HTTP PUT vs GET Comparison

Feature	GET	PUT
Browser Back/Reload	Harmless	May re-submit data (user alerted)
Bookmarked	Can be bookmarked	Cannot be bookmarked
Cached	Can be cached	Not cached
Browser History	Parameters saved in history	Parameters not saved in history
Data Length Restriction	Limited to 2048 characters (URL max)	No restrictions
Security	Less secure (data visible in URL)	More secure (data in body)

Pro Tip: Avoid using GET for sending sensitive information like passwords.

HTTP PUT vs POST Comparison

Aspect	PUT	POST
Purpose	Updates or replaces an existing resource	Adds a new resource or appends to a collection
Request URI	Refers to the resource being updated or created	Refers to the resource handling the data
Idempotence	Idempotent: multiple requests yield the same result	Non-idempotent: may create duplicates

In practical terms, PUT is ideal for updating resources, while POST is preferred for creating new ones.

The HTTP PUT method plays a vital role in REST APIs for updating resources. Its idempotent nature and flexibility in handling large data make it an essential tool for developers working on modern web applications. Understanding the differences between PUT, POST, GET, and PATCH ensures efficient and secure API design.

Keep Learning 🙂