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

What Are HTTP Methods?

HTTP methods (also called HTTP verbs) define the type of action a client wants to perform on a resource. They're defined in the HTTP specification and carry semantic meaning that servers, browsers, CDNs, and caches understand. In REST API design, choosing the correct HTTP method is essential for creating predictable, interoperable APIs.

How to Choose the Right HTTP Method

1. Determine the operation type — reading, creating, updating, or deleting.
2. Consider idempotency — safe methods don't change state; idempotent methods can be called multiple times safely.
3. Think about caching — GET responses can be cached; POST/PUT/DELETE should not be.
4. Use PATCH for partial updates — don't send the whole resource when only one field changes.
5. Use DELETE for removal — even when soft-deleting, the semantic intent is deletion.

HTTP Methods Reference

GET — Retrieve a Resource

GET requests retrieve data without modifying anything. They are safe and idempotent — multiple identical GET requests have the same effect as one. GET responses can be cached by browsers and CDNs. Never put sensitive data in GET query parameters as they appear in server logs and browser history.

GET /users          # List all users
GET /users/123      # Get user with ID 123
GET /users?role=admin  # Filter users by role

POST — Create a Resource

POST creates a new resource. It is neither safe nor idempotent — sending the same POST twice typically creates two resources. POST is also used for actions that don't fit other verbs (e.g., POST /auth/login).

POST /users         # Create new user
POST /orders        # Place new order
POST /auth/login    # Authenticate (action)

PUT — Replace a Resource

PUT replaces an entire resource with the provided representation. It is idempotent — sending the same PUT request twice produces the same result. If the resource doesn't exist, some APIs create it; others return 404.

PUT /users/123      # Replace user 123 completely

PATCH — Partial Update

PATCH applies a partial modification to a resource. Only include the fields you want to change. Unlike PUT, PATCH is not required to be idempotent (though it often is in practice).

PATCH /users/123    # Update only specific fields
Body: {"email": "[email protected]"}

DELETE — Remove a Resource

DELETE removes the specified resource. It is idempotent — deleting the same resource twice should return the same result (200/204 on first deletion, 404 on subsequent calls is common).

DELETE /users/123   # Delete user 123

HEAD and OPTIONS

HEAD is identical to GET but returns only headers, no body. Useful for checking if a resource exists. OPTIONS describes the communication options for a resource, commonly used for CORS preflight requests.

Use Cases

REST CRUD Mapping

A typical REST resource maps cleanly: GET (read), POST (create), PUT/PATCH (update), DELETE (delete). This consistency makes APIs predictable and easier to document.

Idempotency in Distributed Systems

In microservices, network failures can cause requests to be retried. Idempotent methods (GET, PUT, DELETE) are safe to retry. For non-idempotent POST requests, use idempotency keys to prevent duplicate operations.

Frequently Asked Questions

What is the difference between PUT and PATCH?

PUT replaces the entire resource — you must send all fields even those not changing. PATCH sends only the fields to update, leaving others unchanged. Use PATCH when updating a large resource with many fields.

Is GET always safe to use?

GET is semantically safe (shouldn't change state), but you can write poorly-designed APIs where GET requests cause side effects (e.g., GET /deleteUser). This violates HTTP semantics, breaks browser prefetching, and prevents caching. Always make GET requests idempotent and side-effect-free.

When should I use POST vs PUT for creation?

Use POST when the server assigns the resource ID (most common). Use PUT when the client knows the resource ID: PUT /users/specific-uuid. POST to a collection creates a child resource; PUT to a specific URL creates or replaces that resource.

What HTTP status code should DELETE return?

Common responses: 200 with a response body, 204 with no body (most common), or 202 if the deletion is async and queued. Return 404 if the resource doesn't exist (or 204 again, since the end state is the same — no resource).

What is an idempotent HTTP method?

An idempotent method produces the same result regardless of how many times it's called. GET, PUT, and DELETE are idempotent. POST is not. Idempotency is crucial for retry logic in unreliable networks.