HTTP Methods: GET, POST, PUT, PATCH, and DELETE

Every time the frontend communicates with a backend, it sends a request.

Maybe it wants to retrieve a user's profile. Maybe it wants to register a new account, update an email address, or delete a record.

But how does the server know what the client wants to do?

That's where HTTP methods come in.

HTTP methods describe the intended action of a request. They help clients and servers communicate consistently, making APIs easier to understand, build, and maintain.

If you've ever worked with a REST API, you've probably encountered GET, POST, PUT, PATCH, and DELETE.

Let's understand what each one does, when to use it, and the mistakes worth avoiding.

1. GET — Retrieve Data

Imagine you're building a user management API. A user wants to view their profile.

The frontend sends:

GET /users/42 HTTP/1.1
Host: api.example.com

The server retrieves the user with ID 42 and returns the information.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Evans",
  "email": "[e-mail]"
}

That's the purpose of GET: retrieve a resource without requesting a change to the server's state.

Common examples include:

• Fetching a list of products.
• Viewing a user's profile.
• Retrieving an order's details.
• Searching for available courses.

For example:

GET /products
GET /users/42
GET /orders/1001

One important detail: GET is intended to be safe, meaning the request itself shouldn't change the resource's state. Reading a profile shouldn't unexpectedly delete a user or charge their account.

Think of GET as asking, "Can you show me this?"

2. POST — Create or Submit Data

Now imagine someone registers a new account.

The client needs to send information to the server:

POST /users HTTP/1.1
Content-Type: application/json

{
  "name": "Evans",
  "email": "[e-mail]"
}

The backend validates the input, checks the relevant business rules, and creates the account if everything is valid.

A successful response might look like this:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 43,
  "name": "Evans",
  "email": "[e-mail]"
}

Notice the 201 Created status code. It communicates that a new resource was successfully created.

POST is commonly used for:

• Registering users.
• Creating orders.
• Submitting forms.
• Sending messages.
• Triggering operations such as a payment request.

For example:

POST /users
POST /orders
POST /messages

However, POST isn't exclusively for creating resources. It can also submit data for processing or trigger an operation.

Think of POST as saying, "Here is some data; process it."

3. PUT — Replace a Resource

Suppose a user updates their profile. You might want to replace the current representation of that resource with a new one.

A PUT request could look like this:

PUT /users/42 HTTP/1.1
Content-Type: application/json

{
  "name": "Evans Juma",
  "email": "[e-mail]"
}

The server processes the request and replaces the resource's representation with the supplied one, according to the API's design.

The response might be:

HTTP/1.1 200 OK

Or, if the operation succeeds without returning a response body:

HTTP/1.1 204 No Content

Here's the important distinction: PUT generally represents replacement, not a partial update.

If your API treats the request body as the complete editable representation of a user, omitting a field may cause that field to be reset or removed, depending on the API's rules.

That doesn't mean every field in a database must be overwritten. Server-managed values, such as IDs and creation timestamps, can remain unchanged.

A PUT request can also create a resource at a known URI when the API supports that behavior.

Think of PUT as saying, "Make this resource match the representation I'm sending."

4. PATCH — Update Part of a Resource

What if the user wants to change only their email address?

Sending every profile field again may be unnecessary.

That's where PATCH is useful.

PATCH /users/42 HTTP/1.1
Content-Type: application/json

{
  "email": "[e-mail]"
}

The backend updates the email address while leaving unrelated profile fields unchanged.

For example, the user's name remains the same.

PATCH is commonly used for:

• Updating a profile field.
• Changing an order's status.
• Modifying notification preferences.
• Updating a product's price.

One technical detail worth knowing: the meaning of a PATCH request depends on its patch format and the API's implementation. A JSON body containing one field is a common design, but it isn't the only supported format.

Unlike PUT, PATCH isn't inherently idempotent. Its behavior depends on the operation being performed.

Think of PATCH as saying, "Change this part, but leave the rest alone."

PUT vs PATCH: What's the Difference?

This is one of the most common points of confusion.

Suppose the current user resource is:

{
  "name": "Evans",
  "email": "[e-mail]",
  "city": "Kisumu"
}

You want to change only the city.

With PUT, your API might expect the complete editable representation:

{
  "name": "Evans",
  "email": "[e-mail]",
  "city": "Nairobi"
}

With PATCH, you might send only:

{
  "city": "Nairobi"
}

The distinction is about the intended operation, not simply the number of fields in the request body.

5. DELETE — Remove a Resource

Finally, suppose a user wants to delete an account.

The client sends:

DELETE /users/42 HTTP/1.1
Host: api.example.com

If the operation succeeds, the server might respond:

HTTP/1.1 204 No Content

There is no response body because the server has nothing else to return.

Alternatively, the server could return 200 OK with a confirmation message or resource representation.

DELETE is commonly used for:

• Removing a user account.
• Deleting a product.
• Removing a saved address.
• Deleting a comment.

One important distinction: deleting a resource doesn't necessarily mean immediately erasing every related database record. An application might use soft deletion, retention policies, or other business rules.

Think of DELETE as saying, "Remove this resource."

A Quick Comparison

Here's a simple reference you can return to when building an API.

Method	Main purpose	Example	Typical success response
GET	Retrieve data	GET /users/42	200 OK
POST	Create or process data	POST /users	201 Created
PUT	Replace a resource representation	PUT /users/42	200 OK or 204
PATCH	Partially modify a resource	PATCH /users/42	200 OK or 204
DELETE	Remove a resource	DELETE /users/42	204 No Content

These are common choices, not rigid rules. The appropriate response depends on what the server actually did.

Two Concepts Every Backend Developer Should take into consideration

Knowing the methods is only the beginning. Two additional concepts help explain why HTTP methods matter.

1. Safe Methods

A method is considered safe when the client isn't requesting a change to the server's state.

GET is safe. It should retrieve information rather than perform an action such as placing an order or deleting an account.

This is why you shouldn't design an API that deletes a user when someone visits:

GET /delete-user/42

Automated systems, browsers, and caches may make GET requests in situations where the user isn't explicitly asking to change data.

2. Idempotency

A method is idempotent when repeating the same request has the same intended effect on the server as making it once.

For example, sending this request once or five times should leave the resource in the same intended state:

PUT /users/42

{
  "name": "Evans",
  "email": "[e-mail]"
}

GET, PUT, and DELETE are defined as idempotent methods. POST is not inherently idempotent, and PATCH is not guaranteed to be idempotent.

For DELETE, this doesn't mean every repeated request must return the same status code. The first request might return 204, while a later request returns 404. The key is that repeating the request shouldn't cause additional unintended changes.

This concept is especially important when dealing with retries, network failures, and payment APIs. A client may need an idempotency key or another application-level mechanism to prevent a repeated payment submission from charging someone twice.

Bringing It All Together

Imagine you're building a simple e-commerce API.

Your frontend needs to:

• View products.
• Create an order.
• Replace a delivery address.
• Change an order's status.
• Delete an item from a saved list.

You could represent those operations with HTTP methods:

GET    /products
POST   /orders
PUT    /users/42/address
PATCH  /orders/1001
DELETE /saved-items/7

Each method communicates the intended action, while the response status code communicates the outcome.

For example:

POST /orders
      |
      v
201 Created

Or:

GET /users/999
      |
      v
404 Not Found

HTTP methods describe what the client wants to do. HTTP status codes describe how the server handled the request.

Together, they make APIs more predictable and easier for developers to work with.

Final Thoughts

These methods are easier to learn through a practical project as you build the APIs.

Start by understanding the five methods:

• GET retrieves.
• POST submits or creates.
• PUT replaces.
• PATCH partially updates.
• DELETE removes.

Then learn the principles behind them, especially safe methods and idempotency.

As you build APIs, you'll discover that choosing the right HTTP method isn't just about making a request work. It's about making your API's behavior clear to other developers and predictable for the systems that depend on it.

And that's one of the small decisions that separates an API that merely works from one that's well designed.

---