HTTP Methods Explained — GET, POST, PUT, PATCH, DELETE

What You'll Learn

• What HTTP methods are and why they exist
• The five core methods: GET, POST, PUT, PATCH, DELETE
• The difference between PUT and PATCH (the most common confusion)
• How methods map to CRUD operations

Why This Matters

Every API call uses one of these methods. Picking the right one is not just convention — it changes how the server treats your request, whether it is safe to retry, and whether caches can store the response. Get this wrong and your API will behave unpredictably.

Simple Explanation

An HTTP method (also called a verb) is a single word at the start of the request line that tells the server what kind of action the client wants to perform:

GET    /users/123     → "give me this user"
POST   /users         → "create a new user"
PUT    /users/123     → "replace this user entirely"
PATCH  /users/123     → "update part of this user"
DELETE /users/123     → "delete this user"

The method is the verb; the URL is the noun. Together they form a sentence.

The Five Methods

"Safe" means the method does not change server state. "Idempotent" means calling it multiple times has the same effect as calling it once. We explain these in lesson 20.

1. GET — Read

GET asks the server to return a resource without modifying it. It is the most common method by far.

Example request

GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json

Example response

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

{"id": 123, "name": "Anita", "email": "anita@example.com"}

2. POST — Create

POST asks the server to create a new resource. The data for the new resource goes in the request body.

Example request

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name": "Anita", "email": "anita@example.com"}

Example response

HTTP/1.1 201 Created
Content-Type: application/json
Location: /users/123

{"id": 123, "name": "Anita", "email": "anita@example.com"}

Note the 201 Created status and the Location header pointing to the new resource's URL.

3. PUT — Replace Entirely

PUT replaces an entire resource. The body contains the full new state of the resource. If a field is missing from the body, the server should remove or reset it.

Example request

PUT /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name": "Anita Sharma", "email": "anita.sharma@example.com"}

If the user previously had a phone field, after this PUT it should be gone (or reset to null), because the client did not include it.

4. PATCH — Update Part

PATCH updates only the fields included in the body. Everything else stays as it was.

Example request

PATCH /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

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

Only the email changes. Name, phone, and every other field stay the same.

PUT vs PATCH — the key difference

5. DELETE — Remove

DELETE asks the server to remove a resource.

Example request

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

Example response

HTTP/1.1 204 No Content

204 means "successful, no body to return." Some APIs return 200 with a small confirmation JSON instead.

Methods Map to CRUD

The five methods map to the four CRUD (Create, Read, Update, Delete) operations:

REST APIs (covered in Module 3) follow this mapping closely.

Common Mistakes

1. Using POST for everything. Some APIs use POST for reads, updates, and deletes. This works but breaks caches, confuses proxies, and makes the API harder to reason about. Use the right method.
2. Sending a body with GET. The HTTP spec does not forbid it, but many servers, proxies, and caches drop the body. If you need to send data with a GET, use query parameters instead.
3. Confusing PUT and PATCH. Sending a partial body to PUT will silently clear fields you did not include. Sending a full body to PATCH may either work or be rejected depending on the API.
4. Expecting DELETE to return the deleted resource. Many APIs return 204 No Content. If you need the resource's final state, GET it before deleting.
5. Treating POST as idempotent. Calling POST /users twice creates two users with two different IDs. If you need idempotency, use an idempotency key (covered in lesson 20).

Practical Exercise (10 minutes)

JSONPlaceholder (jsonplaceholder.typicode.com) is a free fake REST API for testing. Run these cURL commands and observe the response status codes and bodies:

# GET — read post #1
curl -i https://jsonplaceholder.typicode.com/posts/1

# POST — create a new post
curl -i -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"hello","body":"world","userId":1}'

# PUT — replace post #1
curl -i -X PUT https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"id":1,"title":"new title","body":"new body","userId":1}'

# PATCH — update only the title of post #1
curl -i -X PATCH https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"title":"patched title"}'

# DELETE — delete post #1
curl -i -X DELETE https://jsonplaceholder.typicode.com/posts/1

For each one, note the status code (200, 201, 204, etc.) and the response body. You have just exercised all five HTTP methods against a real API.

Mini Challenge

Design the HTTP methods and URLs for a "comments" feature on a blog. You need to: list comments on a post, get one comment, add a comment, edit a comment, delete a comment. Write down the method + URL for each. (Hint: think about whether editing a comment should be PUT or PATCH, and why.)

Key Takeaways