HTTP Methods Explained: GET vs POST vs PUT vs DELETE

HTTP methods tell the server what kind of action the client intends to perform. If you choose the wrong method, caches misbehave, retries become dangerous, APIs get harder to maintain, and frontend or mobile clients end up guessing what your backend really means.

This guide explains GET, POST, PUT, and DELETE in plain English, then adds the production details beginners usually miss: safe vs idempotent behavior, when PATCH is a better fit than PUT, and how method choice affects caching, retries, and API design. If request flow is still new, start with How APIs Work: A Simple Guide for Beginners and then come back here.

Table of Contents

Quick Definition

HTTP methods are verbs attached to requests. They communicate intent before the server even reads the full payload.

At a practical level:

1. GET reads data.
2. POST creates something or starts work.
3. PUT replaces a full resource.
4. PATCH updates part of a resource.
5. DELETE removes a resource.

That sounds simple, but the meaning matters because browsers, proxies, CDNs, gateways, and client SDKs all behave differently based on the method.

Why HTTP Methods Matter

Good method design gives you three major benefits:

1. Predictability Frontend and mobile clients can understand behavior without memorizing custom conventions.
2. Safer retries If a request times out, method semantics help determine whether retrying is safe.
3. Better infrastructure behavior Caches, load balancers, gateways, and observability tools already understand standard HTTP behavior.

If your REST design fundamentals are still forming, this companion guide on What Is REST API? Beginner’s Guide with Examples explains why resource-oriented APIs depend so heavily on correct method semantics.

HTTP Methods at a Glance

Two details are worth calling out:

1. DELETE is idempotent even though the first request changes state. Repeating the same delete should not keep creating new side effects.
2. POST can sometimes be made retry-safe with idempotency keys, but that does not make POST itself inherently idempotent.

How Method Choice Flows Through a Backend

flowchart TD
    A[Client Chooses Method] --> B{GET?}
    B -->|Yes| C[Read Path]
    C --> D[Cache or CDN Check]
    D --> E[Service Reads Data]
    E --> F[200 Response]
    F --> A

    B -->|No| G{POST PUT PATCH DELETE?}
    G --> H[Auth and Validation]
    H --> I[Business Logic]
    I --> J[(Database Write)]
    J --> K[Emit Audit or Event]
    K --> L[2xx or 4xx or 5xx Response]
    L --> A

    A --> M{Timeout or Network Drop?}
    M -->|Retry Read| C
    M -->|Retry Write?| N[Check Idempotency Rules]
    N --> H

    classDef http fill:#e8f0fe,stroke:#1a73e8,stroke-width:2px,color:#000000;
    class A,B,C,D,E,F,G,H,I,J,K,L,M,N http;

The big idea is that reads and writes move through very different operational paths. GET is often optimized for caching and speed. Write methods tend to require auth, validation, transactions, audit trails, and retry controls.

GET: Read Data Safely

Use GET when the client wants to fetch a representation of a resource without changing server state.

Examples:

• GET /products
• GET /products/sku_123
• GET /orders?status=shipped&limit=20

Why GET is special:

1. It is safe by definition, meaning the client is asking to read, not mutate.
2. It is idempotent, so repeating the same GET should not create more side effects.
3. It is the method caches and CDNs understand best.

That is why product listings, blog pages, profile lookups, and search results usually use GET.

Real-world example:

An e-commerce site may serve GET /products/sku_123 through a CDN or edge cache. If 50,000 users request the same product page during a sale, the backend can survive because the method is designed for cache-friendly reads.

One warning: GET should not secretly mutate important business state. Incrementing metrics or access logs is fine. Charging a credit card or marking an order shipped is not.

POST: Create or Trigger Work

Use POST when the client wants the server to create a new resource or perform a server-defined action.

Examples:

• POST /orders
• POST /users
• POST /payments/authorize

Typical POST create request:

POST /api/v1/orders HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: 9d8ac220-6f81-4c4a-9c3f-53b5b0f3d9b3

{
  "userId": "u_42",
  "items": [
    { "sku": "book-101", "quantity": 2 }
  ]
}

Typical response:

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

{
  "orderId": "ord_9001",
  "status": "pending_payment"
}

Why POST needs extra care:

1. It is not safe.
2. It is not idempotent by default.
3. Retries can duplicate side effects unless you design around them.

This is why payment and order APIs often add idempotency keys. If the first request succeeds but the client loses the response, a retry with the same key can return the original result instead of creating a second order.

PUT vs PATCH: Full Replace vs Partial Update

Many beginners learn PUT as “update,” but that is not specific enough.

Use PUT for full replacement

PUT means the client is sending the desired full state of a resource representation.

Example:

PUT /api/v1/users/u_42 HTTP/1.1
Content-Type: application/json

{
  "name": "Priya",
  "email": "priya@example.com",
  "marketingOptIn": false
}

If your API treats PUT as full replacement, missing fields matter. A missing field may be cleared or reset depending on design.

Use PATCH for partial updates

PATCH is a better fit when the client wants to change only a few fields.

Example:

PATCH /api/v1/users/u_42 HTTP/1.1
Content-Type: application/json

{
  "marketingOptIn": true
}

This distinction matters in production:

1. PUT is easier to reason about if you truly replace the full document.
2. PATCH avoids accidental overwrites when clients only know part of the current state.
3. PATCH often needs stronger validation rules because partial mutations can interact in surprising ways.

If you already understand client-server architecture, think of PUT as “here is the whole desired server-side resource” and PATCH as “apply these changes to what already exists.”

DELETE: Remove a Resource Intentionally

Use DELETE when the client wants a resource removed.

Examples:

• DELETE /sessions/s_123
• DELETE /drafts/d_400
• DELETE /cart/items/item_9

Important production nuance:

1. DELETE is usually idempotent.
2. The first delete may return 204 No Content.
3. A repeated delete may return 404 Not Found or still return 204, depending on API policy.

Those different responses do not automatically break idempotency. The key idea is that repeating the delete should not create extra business damage beyond the first successful deletion.

Many systems also implement soft deletes instead of hard deletes. In that design, DELETE changes a record to deleted = true or sets a deletedAt timestamp while keeping the data for audit or recovery.

Safe vs Idempotent vs Cacheable

These three words are easy to confuse, and interviews often test them directly.

Safe

A safe method is meant for read-only intent. GET is the most important example.

Practical meaning:

• The client should not ask the server to change important business state.
• Infrastructure can make stronger assumptions about read behavior.

Idempotent

An idempotent method can be repeated and still converge on the same intended end state.

Examples:

1. Repeating GET /products/sku_123 just reads again.
2. Repeating PUT /users/u_42 with the same full payload should leave the user in the same state.
3. Repeating DELETE /sessions/s_123 should not create new side effects after the session is already gone.

This is critical for retry logic. If a network timeout happens, idempotent operations are usually safer to retry automatically.

Cacheable

Cacheable means intermediaries or clients can reuse a response under defined rules.

In practice:

1. GET is the main cache-friendly method.
2. Some other methods can be cacheable in theory with explicit controls, but most production systems treat write methods as non-cacheable.

If transport behavior is still fuzzy, this HTTP vs HTTPS guide is useful context because method semantics still ride over the same secure HTTP pipeline.

Common Mistakes Developers Make

1. Using GET for destructive actions

Bad example:

GET /deleteUser?id=42

This is dangerous because crawlers, previews, or caches may trigger the URL. Destructive work should never hide behind a read method.

2. Using POST for every endpoint

Some teams use POST everywhere because it feels flexible. That throws away one of HTTP’s best advantages: shared semantics that tooling already understands.

3. Treating PUT like partial update

If clients assume PUT means “update whichever fields I happened to send,” they can accidentally erase data. If partial update is the real contract, PATCH is clearer.

4. Ignoring idempotency for payments or order creation

Network failures are normal. Without idempotency controls, a simple retry can create duplicate charges or duplicate orders.

5. Returning vague status codes

If every endpoint returns 200 with a custom "success": false body, clients lose the value of standard HTTP semantics. Use status codes as part of the contract, not as decoration.

For a broader learning path beyond this single post, browse the Web Fundamentals hub and the API tag archive.

Real-World Example: Product and Order API

Imagine a storefront backend with these endpoints:

1. GET /products/sku_123
2. POST /orders
3. PUT /users/u_42/preferences
4. PATCH /users/u_42/preferences
5. DELETE /cart/items/item_9

How these choices affect real systems:

1. Product catalog GET lets browsers, CDNs, and reverse proxies cache hot product pages.
2. Order creation POST is correct because each order is a new server-side event with possible payment side effects.
3. Preference overwrite PUT works if the client truly owns the full preference document.
4. Preference tweak PATCH is safer if mobile apps only change one or two settings at a time.
5. Cart cleanup DELETE makes it obvious that the item should no longer exist in the cart.

This is where method selection stops being textbook theory and becomes operations work. The wrong method increases duplicate writes, stale cache bugs, confusing SDK behavior, and incident response time.

Interview Questions

1. Why is GET considered safe but still allowed to have side effects like logging?

Safe does not mean “nothing at all happens on the server.” It means the client is not asking for a meaningful business-state change. Logging, metrics, and tracing can still happen because they are operational side effects, not the primary domain action.

In interviews, I would say the important distinction is user intent. If the request is supposed to read data, then analytics or access logs do not make the method unsafe. Charging a card or deleting a record would.

2. If DELETE is idempotent, why can the second request return 404 instead of 204?

Idempotency is about the repeated request not creating additional intended side effects. It is not a promise that the response payload or status code must always be identical.

The first DELETE may remove the resource and return 204. A second DELETE can reasonably return 404 because the resource is already gone. The system still converged to the same end state: resource absent.

3. When would you choose PUT over PATCH?

I choose PUT when the client can send the full desired representation and the API contract wants replacement semantics. This is common in admin systems or internal APIs where the caller owns the whole document shape.

I choose PATCH when clients change only a subset of fields, especially mobile or browser clients that should not risk overwriting unrelated data. The trade-off is that PATCH requires more careful merge and validation logic.

4. Why should payment creation usually use POST plus an idempotency key?

Payment creation is not naturally idempotent because each successful request can create a new financial side effect. But network retries are unavoidable, so you need an application-level mechanism to recognize that a retried request is the same logical operation.

An idempotency key does that. The first request establishes the result, and later retries with the same key return the original result instead of charging twice. Stripe is a good real-world example of this pattern.

5. Is using POST /orders/{id}/cancel bad API design?

Not automatically. Pure CRUD modeling is a good default, but real business flows include actions like cancel, approve, retry, and refund. If cancel is a domain action with rules, side effects, and audit requirements, an action endpoint can be cleaner than pretending it is just a generic field update.

The real standard is consistency. If a system uses action endpoints, it should do so deliberately and document the rules clearly.

6. What breaks when a team uses POST for reads and writes indiscriminately?

You lose the benefits of standard HTTP semantics. Caches cannot help as much, retries become harder to reason about, SDKs become more confusing, and observability data becomes noisier because all intents look the same at the protocol level.

The short-term gain is convenience. The long-term cost is a backend that constantly needs custom explanations.

Conclusion

HTTP methods are not minor syntax choices. They are the contract that tells clients, servers, and infrastructure what kind of operation is happening. If you pick the right method, your API becomes easier to cache, retry, monitor, document, and evolve.

For beginners, the most important upgrade is simple: stop thinking of methods as controller names and start thinking of them as protocol-level semantics. Once that clicks, API design becomes much more predictable.

References

1. MDN: HTTP Request Methods
   https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
2. RFC 9110 - HTTP Semantics
   https://www.rfc-editor.org/rfc/rfc9110
3. MDN: HTTP Response Status Codes
   https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
4. Stripe Docs: Idempotent Requests
   https://docs.stripe.com/api/idempotent_requests

YouTube Videos

No videos included for this post. The references above are the primary sources.