Use of PUT vs PATCH methods in REST API real life scenarios

Using PUT vs PATCH Methods in REST API: Real Life Scenarios

Hey there tech enthusiasts! 👋 Are you confused about when to use the PUT and PATCH methods in REST API? 🤔 Well, fret no more! In this blog post, we will dive into real-life scenarios where each method shines, and provide easy solutions to common issues. So, let's get started and clear the fog around PUT and PATCH! 🚀

Understanding the Basics

First things first, let's clarify some definitions. According to the HTTP specifications:

PUT ➡️ The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the URI points to an existing resource, the enclosed entity should be considered as a modified version of the one on the server. If the URI does not exist, the server can create a new resource.

PATCH ➡️ The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI.

Additionally, we should note that according to RFC specifications, PUT is idempotent, while PATCH is not. 🔄

Real-Life Example 🌍

To give you a practical understanding, let's look at an example. Suppose we have an API endpoint /users where we can create a user by making a POST request with the data {username: 'skwee357', email: 'skwee357@domain.example'}. The server responds with a 201 status code, along with the resource location (e.g., /users/1). Subsequent calls to GET /users/1 will return the updated user data.

Now, let's say we want to modify the user's email address. As this change involves modifying a specific attribute, we should use the PATCH method by sending a "patch document" (e.g., JSON document: {email: 'skwee357@newdomain.example'}). The server will respond with a 200 status code if the necessary permissions are met.

Uncovering the Difference 🕵️‍♀️

At this point, you might be wondering: "What's the real difference between PUT and PATCH?" 🤷‍♂️ Well, before PATCH was introduced, developers used PUT to update resources. However, PATCH was specifically designed to address the issue of modifying a set of targeted fields.

PUT can be used to replace an entire entity under a specific resource URI. In this case, you need to send the complete entity, rather than just a set of attributes as you would with PATCH. However, you might be wondering why such an operation is not considered as an update or patch.

The primary use case for PUT comes into play when you need to replace or overwrite an entity at a specific resource URI. This can be useful when issuing a PUT on a collection (e.g., /users) to replace the entire collection. However, after the introduction of PATCH, issuing a PUT on a specific entity might seem less common. But hey, different scenarios call for different solutions! 😉

Wrapping It Up

To sum it up, both PUT and PATCH have their own unique roles in REST API:

PUT ➡️ Used for replacing or overwriting an entire entity at a specific resource URI, most commonly used on collections.

PATCH ➡️ Used for targeting a set of changes or modifications to specific attributes of a resource.

So, when working with REST APIs, it's essential to choose the method that best aligns with your specific use case.

That's all for now, folks! We hope this blog post shed some light on the use of PUT and PATCH methods in real-life scenarios. If you have any questions or additional insights to share, feel free to leave a comment below. Happy coding! 💻🙌