HTTP methods GET POST PUT PATCH DELETE: when to use each

HTTP Methods and Their Contracts

HTTP methods are not just labels. They carry semantic contracts that clients, proxies, and caches depend on. Break these contracts and you will have subtle, hard-to-debug bugs.

Safe vs Idempotent

Safe means no side effects — the server state does not change. Idempotent means calling it N times has the same result as calling it once.

The methods

GET    /users/1       # Retrieve. Safe + idempotent. Cacheable.
POST   /users         # Create. Not safe, not idempotent. Each call may create a new resource.
PUT    /users/1       # Full replace. Not safe, but idempotent. Send the complete resource.
PATCH  /users/1       # Partial update. Not safe, conditionally idempotent.
DELETE /users/1       # Remove. Not safe, but idempotent (deleting twice = same result).

Why idempotency matters

If a network timeout happens during a PUT or DELETE, the client can safely retry. Retrying a POST may create duplicate records — which is why APIs that accept POST often return a Location header so the client can check before retrying.

HEAD and OPTIONS

HEAD is identical to GET but returns only headers, no body — useful for checking if a resource exists or validating cache. OPTIONS describes what methods a URL supports — browsers use it automatically for CORS preflight.