RESTful HTTP Methods Explained: GET, POST, PUT, PATCH, DELETE

HTTP methods are the verbs of RESTful APIs — they tell the server what action to perform on a resource with rules about safety, idempotency, and request bodies.

What You’ll Learn

• The five primary HTTP methods and their RESTful semantics
• The difference between safe, idempotent, and unsafe methods
• When to use PUT vs PATCH and POST vs PUT
• How request bodies interact with different methods
• Real-world patterns and common mistakes

Why HTTP Methods Matter

Using the correct HTTP method is the foundation of RESTful API design. It tells every intermediary (caches, proxies, API gateways) exactly how to handle the request. DodaTech’s Durga Antivirus Pro API uses GET for querying threat intelligence (safe and cacheable), POST for submitting suspicious files (unsafe, non-idempotent), and DELETE for removing quarantined items — each method signaling the correct behavior to AWS CloudFront and the load balancer.

    flowchart LR
    subgraph "Safe Methods"
        GET["GET — Read, no side effects"]
    end
    subgraph "Unsafe Methods"
        POST["POST — Create, non-idempotent"]
        PUT["PUT — Replace, idempotent"]
        PATCH["PATCH — Partial update"]
        DELETE["DELETE — Remove, idempotent"]
    end
    GET --> POST
    POST --> PUT
    PUT --> PATCH
    PATCH --> DELETE
    style GET fill:#dbeafe,stroke:#2563eb
    style POST fill:#fef3c7,stroke:#d97706
    style PUT fill:#fef3c7,stroke:#d97706
    style PATCH fill:#fef3c7,stroke:#d97706
    style DELETE fill:#fef3c7,stroke:#d97706
  

GET — Retrieve a Resource

GET is the most common HTTP method. It requests a representation of a resource. Safe means it never changes server state. Idempotent means calling it 100 times returns the same result as calling it once.

GET /api/v1/threats?severity=critical HTTP/1.1
Host: api.durga-antivirus.com
Accept: application/json

// Response: 200 OK
{
  "threats": [
    { "id": "th-001", "name": "Emotet", "severity": "critical" },
    { "id": "th-002", "name": "LockBit", "severity": "critical" }
  ],
  "count": 2
}

Key rules:

• Never include a request body in GET (servers may ignore or reject it)
• Use query parameters for filtering, sorting, and pagination
• Responses should be cacheable (add Cache-Control headers)
• Always return 200 OK on success, 404 Not Found if the resource doesn’t exist

Why no body? GET requests are often logged, cached, and bookmarked by URLs. If the request data were in the body, those features wouldn’t work.

POST — Create a Resource

POST sends data to the server to create a new resource. It is neither safe nor idempotent — sending the same POST twice creates two resources.

POST /api/v1/threats HTTP/1.1
Host: api.durga-antivirus.com
Content-Type: application/json

// Request body
{
  "name": "NewMalwareVariant",
  "hash": "a1b2c3d4e5f6...",
  "severity": "high"
}

// Response: 201 Created
{
  "id": "th-003",
  "name": "NewMalwareVariant",
  "hash": "a1b2c3d4e5f6...",
  "severity": "high",
  "createdAt": "2026-06-06T10:00:00Z"
}

Key rules:

• Return 201 Created with a Location header pointing to the new resource
• Include the created resource in the response body
• Never use POST for retrieval or deletion
• POST is also used for actions that don’t fit resource semantics (e.g., POST /auth/login)

You might be wondering: “If POST creates a resource, what happens if I send the same POST twice?” You get two resources with different IDs. That’s why payment forms warn you not to refresh — a double POST could charge your card twice. Idempotency keys (a unique token in the header) can prevent this.

PUT — Replace a Resource

PUT replaces an entire resource at a known URI. It is idempotent — sending the same PUT ten times results in the same server state as sending it once.

PUT /api/v1/threats/th-003 HTTP/1.1
Host: api.durga-antivirus.com
Content-Type: application/json

// Request body — replaces the entire resource
{
  "name": "NewMalwareVariant",
  "hash": "a1b2c3d4e5f6...",
  "severity": "critical"
}

// Response: 200 OK
{
  "id": "th-003",
  "name": "NewMalwareVariant",
  "hash": "a1b2c3d4e5f6...",
  "severity": "critical",
  "updatedAt": "2026-06-06T12:00:00Z"
}

PUT vs POST: The client decides the URI in PUT. PUT /api/v1/threats/th-003 means “put this data at this exact location.” If the resource exists, replace it. If it doesn’t, create it there. POST leaves URI creation to the server.

Why is PUT idempotent? Because you’re saying “set this URI to this exact representation.” No matter how many times you repeat it, the resource ends up in the same state.

PATCH — Partially Update a Resource

PATCH applies a partial modification to a resource. It is not necessarily idempotent — applying the same PATCH twice might have different effects (e.g., incrementing a counter).

PATCH /api/v1/threats/th-003 HTTP/1.1
Host: api.durga-antivirus.com
Content-Type: application/json

// Request body — only include fields to update
{
  "severity": "low"
}

// Response: 200 OK
{
  "id": "th-003",
  "name": "NewMalwareVariant",
  "hash": "a1b2c3d4e5f6...",
  "severity": "low",
  "updatedAt": "2026-06-06T14:00:00Z"
}

PUT vs PATCH: PUT replaces the entire resource — if you omit a field, it gets cleared. PATCH only changes the fields you specify. Use PATCH when you want to update one or two fields without sending the entire resource.

DELETE — Remove a Resource

DELETE removes a resource. It is idempotent — after the first successful delete, subsequent DELETEs return 404 but the server state doesn’t change.

DELETE /api/v1/threats/th-003 HTTP/1.1
Host: api.durga-antivirus.com

// Response: 204 No Content (no body)

Key rules:

• Return 204 No Content on successful deletion (no response body needed)
• Return 404 Not Found if the resource doesn’t exist
• Consider soft-deletes for recoverability (mark as deleted, don’t actually remove)

Common Mistakes

1. Using POST for Everything

Some APIs use POST for every operation with different action parameters (POST /api?action=getUser). This breaks REST semantics and defeats caching. Each HTTP method has a specific job — use it.

2. Including a Body in GET Requests

GET requests with JSON bodies confuse proxies and caches. Some servers ignore the body entirely. Use query parameters or headers instead.

3. Confusing PUT and PATCH

PUT replaces the entire entity. If you send PUT /users/123 with only {"email": "new@example.com"}, the user will lose their name, phone, and address. Use PATCH for partial updates.

4. Returning 200 for Everything

Every status code has a meaning. Returning 200 for a creation response means clients can’t distinguish between “successfully created” and “successfully retrieved.” Use 201 for creation, 204 for deletion.

5. Not Handling Idempotency for POST

Payment processing, order creation, and file uploads should handle duplicate POST requests. Use idempotency keys (Idempotency-Key header) to detect and prevent duplicates.

Practice Questions

1. Which HTTP methods are idempotent? Which are safe?
2. Why shouldn’t you include a body in a GET request?
3. What is the difference between PUT /users/123 and POST /users?
4. Why is PATCH not guaranteed to be idempotent?
5. What status code should a DELETE endpoint return on success?

Answers:

1. Idempotent: GET, PUT, DELETE. Safe: GET only. POST and PATCH are neither safe nor idempotent.
2. GET bodies are not part of the HTTP standard for caching and logging. Proxies and CDNs may ignore or reject them.
3. PUT /users/123 replaces the user at that known URI; POST /users creates a new user at a server-generated URI. PUT includes the identifier; POST doesn’t.
4. PATCH instructions like {"increment": "visits"} change state differently on each call. Even field updates are idempotent only if the PATCH sets absolute values.
5. 204 No Content — the resource is gone, so there’s nothing to return.

Challenge: Design the HTTP method and URI for: “Submit a suspicious file hash to Durga Antivirus Pro for analysis” and “Update the threat level of an existing threat report.” Show the full request and expected response for each.

FAQ

Try It Yourself

Run these curl commands to see each method in action:

# GET — safe, idempotent
curl -i https://jsonplaceholder.typicode.com/posts/1

# POST — unsafe, non-idempotent
curl -i -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"Test","body":"Hello","userId":1}'

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

# PATCH — partial update
curl -i -X PATCH https://jsonplaceholder.typicode.com/posts/1 \
  -H "Content-Type: application/json" \
  -d '{"title":"Partially Updated"}'

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

Notice the different status codes: 200 for GET/PUT/PATCH, 201 for POST, and 204 (or 200) for DELETE.

What’s Next

What’s Next

Congratulations on completing this Restful Methods tutorial! Here’s where to go from here:

• Practice daily — Consistency is more important than long study sessions
• Build a project — Apply what you learned by building something real
• Explore related topics — Check out other tutorials in the same category
• Join the community — Discuss with other learners and share your progress

Remember: every expert was once a beginner. Keep coding!