What are the 5 methods of REST API?

REST API methods: GET, POST, PUT, PATCH, and DELETE explained

what are the 5 methods of rest api Understanding these HTTP verbs is essential for designing robust and efficient web services. Each method has a specific role in data manipulation, and using them correctly prevents errors and data inconsistency. Whether you are building or consuming APIs, knowing the differences ensures reliable communication. Explore the core methods and their properties to master RESTful design.

The Five Core HTTP Methods Every REST API Uses

REST APIs are the backbone of modern web communication, allowing different software systems to talk to each other over the internet. At the heart of this interaction are five primary HTTP methods, often referred to as verbs. These methods—GET, POST, PUT, PATCH, and DELETE—correspond directly to the fundamental CRUD operations (Create, Read, Update, and Delete) that define how data is managed. Understanding these five methods is your first step toward designing, building, or even just using web services effectively.

GET: Retrieving Data

The GET method is the most common and perhaps the simplest. It is used to request data from a specific resource. Think of it like a search query in a librarys catalog—you are asking for information without changing anything.

A well-designed GET request is safe and idempotent ^[1][3]. This means it should never modify the state of the server, and calling it once or a hundred times will return the same result, provided no other actions have been taken to change the data on the server ^[2][3]. For example, a browser making a GET request to \/api\/users would expect to receive a list of users.

POST: Creating New Resources

When you need to add a new item to a collection, you use the POST method. It sends data to the server to create a new resource. For instance, filling out a form on a website to create a new user account will typically send a POST request to the server ^[7].

The server then processes the data and creates the new user. A key characteristic of POST is that it is not idempotent ^[5]. Sending the same POST request twice will likely result in two separate resources being created (e.g., two new user accounts with the same information). The server usually decides the final URI for the newly created resource and returns it to the client.

PUT: Replacing Resources Entirely

The PUT method is used to update an existing resource by completely replacing it with the data provided in the request. Imagine you have a document on a server, and you want to overwrite the whole document with a new version. You would send a PUT request to the documents specific URL, including the full, updated content ^[2].

PUT is idempotent ^[3]. If you send the same PUT request multiple times, the result on the server will be the same each time—the resource will be replaced with the same data over and over.

In some designs, PUT can also be used to create a resource if you know the exact URL where it should reside, though this is less common than using POST for creation.

PATCH: Applying Partial Modifications

While PUT replaces an entire resource, PATCH is used for partial modifications. If you have a user profile with a first name, last name, and email address, and the user only wants to change their email, a PATCH request would only need to send the new email address.

This is more efficient than using PUT, which would require sending all the users data again ^[8]. The difference between put and patch in rest api is fundamental; idempotence of PATCH is not guaranteed by the HTTP specification in the same way as PUT; it depends on how the server implements the patch instructions. However, when used correctly, it is the ideal tool for making minor updates to a resource without transferring unnecessary data.

DELETE: Removing Resources

The name says it all: the DELETE method is used to remove a specified resource from the server. A successful DELETE request to \/api\/users\/123 would remove the user with the ID 123 ^[1]. Like PUT, DELETE is idempotent. The first request will delete the resource. Subsequent requests, while they may receive a different response (like a 404 Not Found), will not change the state of the server any further—the resource is already gone ^[8].

Comparison: HTTP Methods, CRUD, Safety, and Idempotence

To solidify your understanding, lets look at how these five methods map to database operations and their critical properties: safety and idempotence. A safe method is one that doesnt alter the servers state. An idempotent method guarantees that multiple identical requests have the same effect as a single request ^[3].

GET: Corresponds to Read. It is Safe (yes) and Idempotent (yes). POST: Corresponds to Create. It is Safe (no) and Idempotent (no). PUT: Corresponds to Update\/Replace. It is Safe (no) and Idempotent (yes). PATCH: Corresponds to Update\/Modify. It is Safe (no) and Idempotent (no - though implementations can vary). DELETE: Corresponds to Delete. It is Safe (no) and Idempotent (yes).

Understanding these properties is crucial for building reliable APIs, especially when dealing with network issues where what are the http methods used in rest api calls might need to be retried.

Practical API Request Examples

Seeing these methods in action makes the concepts concrete. Here are typical examples of how you might interact with a resource called products.

GET all products: GET https:\/\/api.example.com\/products GET a single product with ID 123: GET https:\/\/api.example.com\/products\/123 POST a new product (the server generates the ID): POST https:\/\/api.example.com\/products Body: { name: Wireless Mouse, price: 29.99 } PUT to replace product 123 entirely: PUT https:\/\/api.example.com\/products\/123 Body: { name: Wireless Mouse Pro, price: 49.99 } PATCH to update only the price of product 123: PATCH https:\/\/api.example.com\/products\/123 Body: { price: 39.99 } DELETE product 123: DELETE https:\/\/api.example.com\/products\/123

Clearing Up Common Confusions: PUT vs. POST, PUT vs. PATCH

Its extremely common for developers, especially when starting out, to get a few of these methods mixed up. Lets tackle the most frequent points of confusion head-on.

POST vs. PUT for Creating Resources

The biggest point of confusion is often when to use post vs put in rest api for creation. The simple rule of thumb is: use POST when you want the server to be in charge of generating the resources identifier (like the ID).

Use PUT when the client is specifying the exact identifier. For example, when adding a new user, you usually dont know the new users ID in advance. So you POST to \/api\/users. The server creates the user, assigns an ID like 456, and can tell you the new resource lives at \/api\/users\/456. If you were creating a new blog post with a custom slug you control, like my-first-post, you might PUT to \/api\/posts\/my-first-post ^[10].

PUT vs. PATCH for Updating Resources

Another common source of confusion is the difference between PUT and PATCH. Remember this: PUT is for a complete replacement, while PATCH is for a partial update. If a resource has ten fields, and you send a PUT request with only one field, a well-designed API should treat the missing nine fields as if they are being set to null or their default values—you are replacing the whole resource with the new representation you sent. With a PATCH request, sending only one field means you are only modifying that one field, leaving the other nine untouched ^[5].

Real-World Example: Building a Simple To-Do List API

Lets put this all together with a relatable scenario. Imagine youre building a to-do list application.

When your app loads, it uses a GET request to https:\/\/api.mytodo.com\/tasks to retrieve the users existing tasks and display them. When the user types in a new task, like Buy groceries, and hits Add, your app sends a POST request to https:\/\/api.mytodo.com\/tasks with a JSON body containing the task description. The server creates a new task resource, maybe with an ID of 501, and returns the full task object to your app.

Later, the user checks the task off as complete. Your app might send a PATCH request to https:\/\/api.mytodo.com\/tasks\/501 with a body like { completed: true }. This updates only the completed status field without touching the tasks description. If the user wants to edit the task description from Buy groceries to Buy organic groceries, your app could send a PUT request to the same URL, https:\/\/api.mytodo.com\/tasks\/501, with the complete, updated task representation. Finally, when the user deletes the task, your app sends a DELETE request to https:\/\/api.mytodo.com\/tasks\/501.

Beyond the Basics: Other HTTP Methods

While GET, POST, PUT, PATCH, and DELETE are the workhorses of restful api http methods, the HTTP protocol defines several other methods that serve specific purposes. You might encounter HEAD, which works like GET but returns only the headers (metadata) without the actual resource body, useful for checking if a resource has been modified.

OPTIONS is used by clients to discover which HTTP methods a server supports for a given URL, which is crucial for CORS (Cross-Origin Resource Sharing) preflight requests ^[1]. Others like CONNECT and TRACE are more specialized and rarely used directly in application-level API design ^[1].

Key Takeaways for Your API Journey

REST API Method Comparison

GET

Yes

On a single resource (e.g., /users/123) or a collection (/users)

Read

Yes

POST

No

Almost always on a collection (e.g., /users) to create a new subordinate resource.

Create

No

PUT

Yes

On a specific resource (e.g., /users/123). The client knows the resource's URL.

Update/Replace

No

PATCH

Not guaranteed

On a specific resource (e.g., /users/123). The client knows the resource's URL.

Update/Modify

No

DELETE

Yes

On a specific resource (e.g., /users/123).

Delete

No

API Designer Mai's Journey: From Confusion to Clarity

Mai, a junior developer at a tech startup in Ho Chi Minh City, was tasked with building a new API for their mobile app. She knew the five methods but was terrified of making a mistake. Her first design used POST for every action that changed data, leading to inconsistent states when users with poor network connections double-tapped the 'save' button, creating duplicate records.

Frustrated, Mai spent a weekend reading documentation and running tests. The breakthrough came when she visualized her API as a library. 'POST is like dropping a new, uncatalogued book on the librarian's desk,' she thought. 'PUT is like putting a book back in its specific, labeled spot on the shelf, replacing the old one entirely. And PATCH is just correcting a typo on a book that's already in place.'

With this mental model, Mai redesigned her API. She used POST for creating new orders (letting the server assign the order ID), PUT for updating an entire user profile (replacing the old profile with a completely new one), and PATCH for updating just the status of an order. She also ensured her DELETE endpoint was idempotent, so calling it twice on the same order wouldn't cause an error.

After implementing these changes, Mai's API became robust. The number of data-related bugs reported from the mobile team dropped significantly. She finally felt confident in her design skills, and her new mental model made explaining REST APIs to new team members much easier.