HTTP PUT vs PATCH: What's the Difference?

HTTP requests are the backbone of modern web development. They allow us to interact with APIs and retrieve data from servers. Two of the most commonly used HTTP requests are PUT and PATCH. In this blog post, we will explore the differences between these two requests and when to use them.

💡

Quickly test and debug your APIs with Apidog by easily performing HTTP requests, including PUT and PATCH. Get started for free by downloading now!

button

What is an API?

Before we dive into the differences between PUT and PATCH, let’s first define what an API is. An API stands for Application Programming Interface. It is a set of defined rules that enable different applications to communicate with each other. APIs act as an intermediary layer that processes data transfers between systems, letting companies open their application data and functionality to external third-party developers, business partners, and internal departments within their companies.

The definitions and protocols within an API help businesses connect the many different applications they use in day-to-day operations, which saves employees time and breaks down silos that hinder collaboration and innovation. For developers, API documentation provides the interface for communication between applications, simplifying application integration. APIs are used to bridge the gaps between small, discrete chunks of code to create applications that are powerful, resilient, secure, and able to meet user needs.

Overview of HTTP methods?

HTTP (Hypertext Transfer Protocol) is an application-layer protocol used for transmitting hypermedia documents, such as HTML, over the internet. It facilitates communication between web browsers and web servers, but it can also be used for other purposes. HTTP operates as a client-server protocol, with requests typically initiated by the recipient, usually the web browser. The complete document is reconstructed from different sub-documents fetched, including text, layout description, images, videos, scripts, and more.

Clients and servers communicate by exchanging individual messages (rather than a continuous stream of data). The messages sent by the client (usually a web browser) are called requests, and the messages sent by the server in response are called responses. HTTP is an extensible protocol that has evolved over time and is sent over TCP or over a TLS-encrypted TCP connection. Due to its extensibility, it is used not only to fetch hypertext documents but also to retrieve images and videos or to post content to servers, such as with HTML form results. Additionally, HTTP can be used to fetch parts of documents to update web pages on demand.

Introduction of HTTP PUT

HTTP PUT is an HTTP method used to create a new resource or overwrite a representation of the target resource that is known by the client. It is similar to the HTTP POST method, which is used to add a resource on the server.

However, unlike POST, PUT is idempotent, which means that calling it once or several times successively has the same effect (that is no side effect). 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.

Understanding HTTP PATCH

HTTP PATCH is a request method used to make partial modifications to an existing resource. It is similar to the HTTP PUT method, which is used to create a new resource or overwrite a representation of the target resource that is known by the client. However, unlike PUT, PATCH is used to modify only a part of the resource, whereas PUT replaces the entire resource.

The PATCH method provides an entity containing a list of changes to be applied to the resource requested using the HTTP Uniform Resource Identifier (URI). The list of changes is supplied in the form of a PATCH document. The PATCH method is used to update resources with partial JSON data.

When to use HTTP PUT

The difference between HTTP PUT and HTTP POST is that PUT is idempotent, which means that calling it once or several times successively has the same effect (that is no side effect). 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.

HTTP PUT is best used when you want to completely replace an existing resource with new data. For example, if you have a user profile that contains multiple fields such as name, email, and phone number, and you want to update all of these fields at once, you would use a PUT request.

Here’s an example of how you might use an HTTP PUT request to update the content of an existing file on a server:

PUT /example.html HTTP/1.1
Host: sample.com
Content-Type: text/html
Content-Length: 20

<p>Updated File</p>

In this example, the PUT request is sent to the resource located at /example.html. The Content-Type header specifies that the request body is in HTML format. The Content-Length header indicates the size of the request body, which in this case is 20 bytes. The request body contains the new content for the file, which is a simple HTML paragraph element with the text “Updated File”. If the file exists and the server processes the request successfully, it will replace the content of example.html with the new content provided in the request body.‘’

When to use HTTP PATCH

For instance, when updating a single field of the resource, sending the complete resource representation can be cumbersome and uses a lot of unnecessary bandwidth. A PATCH request is considered a set of instructions on how to modify a resource.

HTTP PATCH is best used when you want to update a single field or a few fields in an existing resource. For example, if you have a user profile that contains multiple fields such as name, email, and phone number, and you only want to update the email field, you would use a PATCH request.

Here’s an example of how you might use an HTTP PATCH request to update a user’s email address in a system:

PATCH /api/users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json
If-Match: "e0023aa4e"

{
  "email": "newemail@example.com"
}

In this example, the PATCH request is sent to the resource located at /api/users/123. The Content-Type header specifies that the request body is in JSON format. The If-Match header is used to ensure that the update is only applied if the eTag (a version identifier for the resource) matches the one provided. The request body contains the change to be applied, which in this case is an update to the user’s email address. The server would then process this request and apply the update to the user’s information. If successful, the server might respond with a 200 OK status code and possibly include the updated resource in the response body.

Differences between HTTP PUT and PATCH

HTTP PUT and HTTP PATCH are both HTTP methods used to modify resources, but they differ in how they update the resource.

HTTP PUT is used to create a new resource or overwrite a representation of the target resource that is known by the client. It is suitable for scenarios where you have full control over resource replacement. 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.

HTTP PATCH is used to make partial modifications to an existing resource. It is suitable for scenarios where you need to update only a part of the resource, whereas PUT replaces the entire resource. The PATCH method provides an entity containing a list of changes to be applied to the resource requested using the HTTP Uniform Resource Identifier (URI). The list of changes is supplied in the form of a PATCH document.

The main difference between HTTP PUT and PATCH is the amount of data that is sent in the request. PUT sends the entire resource, while PATCH only sends the fields that are being updated. This means that PUT requests are more expensive in terms of bandwidth and processing power than PATCH requests.

Advantages of HTTP PUT

HTTP PUT is a request method that is used to update or replace an existing resource on the server. Some of the benefits of using HTTP PUT include:

Idempotency: HTTP PUT is an idempotent method, which means that the same request can be made multiple times without causing any side effects.
Atomicity: HTTP PUT is an atomic operation, which means that it either succeeds completely or fails completely. This makes it useful for updating resources that have multiple fields.
Uniform interface: HTTP PUT follows the uniform interface constraint of RESTful web services, which makes it easy to use and understand.
Caching: HTTP PUT requests can be cached by intermediaries such as proxies, which can help to reduce network traffic and improve performance.

Advantages of HTTP PATCH

The PATCH method in HTTP is used to partially update a resource on the server. It allows you to send only the data that needs to be updated, rather than sending the entire resource. This can be advantageous in situations where you want to make small, specific changes to a resource without having to resend the entire resource.

Advantages of using the HTTP PATCH method include:

Efficiency: PATCH allows for more efficient use of network resources by sending only the changes that need to be made, reducing the amount of data transmitted.
Partial Updates: PATCH enables you to update specific parts of a resource without affecting the rest of the resource, providing granular control over updates.
Idempotent: When used properly, PATCH requests are idempotent, meaning that multiple identical requests will produce the same result as a single request, reducing the risk of unintended side effects.

These advantages make HTTP PATCH particularly useful for specific use cases where only a subset of resource data needs to be updated.

How to use Apidog to send requests with HTTP PUT and HTTP PATCH

Apidog is an integrated collaboration platform designed to streamline the process of working with APIs. It combines features from tools like Postman, Swagger, Mock, and JMeter to provide a comprehensive solution for API documentation, debugging, mocking, and automated testing.

button

Apidog allows you to send HTTP requests to test and debug your APIs without needing to redefine them if they are already documented. Using Apidog to send PUT and PATCH requests involves a few steps.

Send HTTP PUT Request with Apidog

To send an HTTP PUT request with Apidog, you can follow these steps:

Open Apidog: Start by opening Apidog and creating a new request.

2. Specify the HTTP Method: Choose PUT as the HTTP method for your request.

3. Enter the URL: Input the URL of the resource you want to update, include any necessary headers, such as Content-Type or Authorization and add the data you want to send in the request body. You can use the json parameter to send JSON data or the data parameter to send form-encoded data.

4. Send the Request: Once you’ve set up your request, send it to the server.

Check the server’s response to your PUT request and handle it accordingly.

By using Apidog, you can maintain data consistency across different systems and ensure that your API development is in strict accordance with your API documentation, leading to more effective collaboration and fewer inconsistencies.

button

Send HTTP PATCH Request with Apidog

Open Apidog: Launch the Apidog application and Start by creating a new request within the application.

2. Select the HTTP Method: Choose PATCH from the list of HTTP methods.

3. Enter the URL: Input the endpoint URL where you want to send the PATCH request, add headers if necessary and in the request body, include the data you wish to partially update.

Execute the request and wait for the response from the server.

Analyze the server’s response to ensure the PATCH request was successful.

button

Best Practices for Using HTTP PUT and HTTP PATCH Requests

When working with HTTP methods such as PUT and PATCH, it’s important to follow best practices to ensure that your API is reliable, efficient, and easy to use. Here are some best practices for using PUT and PATCH requests:

Best Practices for Using HTTP PUT Requests

Use PUT for Complete Updates: PUT should be used when you want to update a resource entirely. It replaces the entire resource with the payload provided in the request body.
Ensure Idempotence: PUT requests should be idempotent, meaning that making multiple identical requests should have the same effect as making a single request.
Include Resource in URL: The URL should contain the identifier of the resource to be updated.

Best Practices for Using HTTP PATCH Requests

Use PATCH for Partial Updates: PATCH should be used for partial updates, i.e., when you only need to update specific fields of a resource.
Handle Non-idempotence Appropriately: PATCH requests are not required to be idempotent. If your implementation is idempotent, it should behave accordingly.
Use a Delta Format: Send only the changes (the delta) you want to apply to the resource, rather than the complete resource.

General Best Practices for using HTTP PUT and HTTP PATCH

Validate Input: Always validate the input data for both PUT and PATCH requests to prevent invalid data updates.
Use ETags for Concurrency Control: Implement ETags to handle concurrent updates and avoid the “lost update” problem.
Return Appropriate Status Codes: Use HTTP status codes correctly to indicate the result of the request (e.g., 200 OK, 204 No Content, 400 Bad Request).
Document Your API: Clearly document the expected behavior of your PUT and PATCH endpoints, including required fields and validation rules.

Conclusion

In conclusion, HTTP PUT and PATCH are both important HTTP requests that are used to update resources on a server. PUT is best used when you want to completely replace an existing resource with new data, while PATCH is best used when you want to update a single field or a few fields in an existing resource. Both requests have their advantages and disadvantages, and the choice between them depends on the specific use case.

By using Apidog, you have the ability to effortlessly send your HTTP requests in order to test and debug your APIs.

button