HTTP Methods in Practice: When to Use GET, POST, PUT, and DELETE

Knowing that GET reads and POST creates is the basics. Becoming a professional means understanding the nuances: when PUT is better than PATCH, why GET must never change data, how DELETE should handle missing resources, and the safety and idempotency contracts each method provides.

---

1. GET: The Read Operation

GET is the most used HTTP method. It retrieves data from the server without changing anything.

Golden Rules of GET

1. Never modify data — GET must be safe (read-only)
2. No request body — Some servers ignore it; others reject it
3. Must be idempotent — Calling it 100 times gives the same result
4. Cacheable — Browsers and CDNs can cache GET responses

GET Patterns

# List all resources (collection)
curl https://jsonplaceholder.typicode.com/posts

# Get a specific resource (by ID)
curl https://jsonplaceholder.typicode.com/posts/1

# Filter with query parameters
curl "https://jsonplaceholder.typicode.com/posts?userId=1"

# Nested resource (posts belonging to user 1)
curl https://jsonplaceholder.typicode.com/users/1/posts

# Pagination
curl "https://api.example.com/products?page=2&limit=20"

# Sorting
curl "https://api.example.com/products?sort=price&order=asc"

# Searching
curl "https://api.example.com/products?q=laptop"

# Field selection (only return specific fields)
curl "https://api.example.com/users?fields=name,email"

When GET Returns Different Status Codes

Scenario	Status	Body
Resource found	200 OK	Resource data
Resource not found	404 Not Found	Error message
Collection is empty	200 OK	Empty array []
Not authenticated	401 Unauthorized	Error message
Not authorized	403 Forbidden	Error message

Important: An empty collection should return 200 OK with [], not 404. The collection exists; it just has no items.

---

2. POST: The Create Operation

POST creates a new resource. The server assigns the ID and any default values.

Golden Rules of POST

1. Creates new data — Each call creates a new resource
2. Not idempotent — Calling twice creates two resources
3. Requires a body — The data for the new resource
4. Returns 201 Created — With the new resource in the body
5. Include Content-Type — Tell the server what format you are sending

POST Patterns

# Create a new post
curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{
    "title": "My New Post",
    "body": "Content here",
    "userId": 1
  }'

Response:

{
  "title": "My New Post",
  "body": "Content here",
  "userId": 1,
  "id": 101
}

What the Server Does with a POST

sequenceDiagram
    participant Client
    participant Server
    participant DB as Database

    Client->>Server: POST /posts + JSON body
    Server->>Server: Validate input
    Server->>Server: Generate ID
    Server->>Server: Set defaults (createdAt, status)
    Server->>DB: INSERT INTO posts
    DB-->>Server: Success
    Server-->>Client: 201 Created + new resource

POST for Non-CRUD Actions

POST is also used for actions that do not fit CRUD:

# Search (when query is complex)
POST /api/search
{"query": "complex search", "filters": {...}, "facets": [...]}

# Login
POST /api/auth/login
{"email": "user@test.com", "password": "secret"}

# Trigger an action
POST /api/reports/generate
{"type": "monthly", "month": "2026-02"}

# Batch operations
POST /api/emails/send-bulk
{"recipients": ["a@b.com", "c@d.com"], "template": "welcome"}

---

3. PUT: The Full Replace Operation

PUT replaces an entire resource with the data you provide.

Golden Rules of PUT

1. Replaces the entire resource — Missing fields may be set to null
2. Must be idempotent — Sending the same PUT twice gives the same result
3. Requires a body — The complete new version of the resource
4. Client provides the ID — PUT targets a specific resource
5. Returns 200 OK — With the updated resource

PUT in Practice

Original resource:

{
  "id": 1,
  "title": "Original Title",
  "body": "Original body text",
  "userId": 1,
  "tags": ["introduction"],
  "status": "published"
}

PUT request (updating title and body):

curl -X PUT https://api.example.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{
    "id": 1,
    "title": "Updated Title",
    "body": "Updated body text",
    "userId": 1,
    "tags": ["introduction"],
    "status": "published"
  }'

Notice you must include all fields, even the ones that did not change. If you omit tags, the resource might lose that field.

PUT Can Create Resources

Some APIs use PUT to create a resource at a specific URL:

# Create user with a specific ID
PUT /users/custom-id-123
{
  "name": "Custom User",
  "email": "custom@test.com"
}

If the resource does not exist, the server creates it. If it does exist, it replaces it. This is called an upsert pattern.

---

4. PATCH: The Partial Update Operation

PATCH updates only the fields you send. Everything else stays the same.

Golden Rules of PATCH

1. Partial update — Only specified fields change
2. Usually idempotent — But depends on implementation
3. Requires a body — Only the fields to change
4. Returns 200 OK — With the complete updated resource

PATCH vs PUT: The Critical Difference

graph LR
    subgraph PUT
        A["Send ALL fields"] --> B["Server replaces entirely"]
    end
    subgraph PATCH
        C["Send ONLY changed fields"] --> D["Server updates those fields"]
    end

    style A fill:#d97706,color:#fff
    style B fill:#d97706,color:#fff
    style C fill:#059669,color:#fff
    style D fill:#059669,color:#fff

Using PATCH to change just the title:

curl -X PATCH https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"title": "Only This Changed"}'

Response — the body stays the same:

{
  "userId": 1,
  "id": 1,
  "title": "Only This Changed",
  "body": "quia et suscipit..."
}

When to Use PUT vs PATCH

Scenario	Use
Form submission with all fields	PUT
Toggle a boolean flag	PATCH
Admin changing user's role	PATCH
Replacing a document	PUT
Changing a password	PATCH
Updating settings	PATCH (usually)
Restoring from backup	PUT

---

5. DELETE: The Remove Operation

DELETE removes a resource from the server.

Golden Rules of DELETE

1. Removes the resource — Permanently (unless soft-delete)
2. Must be idempotent — Deleting a deleted resource should not error
3. Usually no body — Some APIs accept a reason
4. Returns 200 or 204 — 204 if no body, 200 if confirmation body

DELETE in Practice

curl -X DELETE https://jsonplaceholder.typicode.com/posts/1

What Should Happen When Deleting an Already-Deleted Resource?

Approach	Response	Philosophy
Idempotent	204 No Content	The resource is gone — mission accomplished
Strict	404 Not Found	The resource does not exist

Most modern APIs use the idempotent approach: if the resource is already gone, the delete request is still "successful."

Soft Delete vs Hard Delete

Type	What Happens	Recoverable?
Hard Delete	Data removed from database	No
Soft Delete	Data flagged as deleted but kept	Yes

Soft delete is more common in production. The API returns a successful delete response, but the data is actually just marked with a deleted_at timestamp and hidden from normal queries.

---

6. Method Safety and Idempotency Summary

Method	Safe?	Idempotent?	Has Body?	Cacheable?
GET	Yes	Yes	No	Yes
HEAD	Yes	Yes	No	Yes
OPTIONS	Yes	Yes	No	No
POST	No	No	Yes	No
PUT	No	Yes	Yes	No
PATCH	No	Usually	Yes	No
DELETE	No	Yes	Usually no	No

Safe = Does not modify data Idempotent = Same result if called multiple times

---

Summary and Key Takeaways

1. GET is read-only, safe, idempotent, and cacheable.
2. POST creates new resources and is NOT idempotent — calling twice creates duplicates.
3. PUT replaces the entire resource — include all fields.
4. PATCH updates only specified fields — more efficient for small changes.
5. DELETE removes resources and should be idempotent.
6. Understanding safety and idempotency prevents bugs in retry logic.
7. POST is also used for non-CRUD actions like login, search, and batch operations.

---

Lesson Review Quiz