HTTP Methods
A set of request methods to indicate the desired action to be performed for a given resource.
Detailed Explanation
The most common methods are GET (fetch data), POST (submit data), PUT (update entire resource), PATCH (partial update), and DELETE (remove resource). Following RESTful conventions for these methods makes APIs predictable and easier to integrate. Each method has specific semantics regarding idempotency and cacheability that impact system design.
Quick Summary
HTTP methods (verbs) tell the server the intent of a request: GET reads, POST creates, PUT replaces, PATCH partially updates, DELETE removes. Each method has defined semantics around safety, idempotency, and cacheability that proxies and clients rely on.
Key Takeaways
- Safe methods (GET, HEAD, OPTIONS) must not change server state, caches and crawlers depend on this guarantee.
- Idempotent methods (GET, PUT, DELETE, PATCH when designed correctly) produce the same result when retried; POST is intentionally non-idempotent.
- GET responses can be cached by browsers, CDNs, and proxies; POST/PUT/DELETE generally cannot.
- PUT replaces an entire resource; PATCH applies a partial update. Mixing them up causes lost data.
- OPTIONS is what CORS preflights use, and HEAD returns headers only, both are easy to forget when designing endpoints.
When to use it
- Designing RESTful APIs where the verb implies the action and the URL identifies the resource.
- Optimistic UI updates: knowing PUT/DELETE are idempotent lets clients safely retry on network failure.
- CDN caching strategies driven by method, only GET/HEAD are cached by default.
- Browser behavior: the back button replays GETs but warns before resending POSTs.
Common Mistakes
- Using GET to mutate state (delete via /users/123/delete), crawlers and prefetchers can trigger it without user action.
- Treating PUT and PATCH as interchangeable; a PUT with missing fields blanks them out, while a PATCH would leave them alone.
- Returning 200 with an error body instead of using a 4xx or 5xx status, clients can't tell success from failure.
- Designing POST to be idempotent ad-hoc, then forgetting and double-charging users on a retry.
HTTP Methods, Frequently Asked
Should I use PUT or PATCH for updates?
PUT if the client always sends the complete resource; PATCH if it sends only the fields that change. PATCH is friendlier for partial form updates; PUT is simpler when the resource is small and always fully owned by the client.
Why isn't POST idempotent?
POST is meant for actions like "create a new order" where repeating it produces another order. To make POST safely retryable, clients pass an idempotency key the server uses to deduplicate within a window, common in payment APIs.
What's the difference between PUT and POST for creation?
PUT creates or replaces a resource at a URL the client chose (PUT /users/alice); POST creates a resource whose URL the server assigns (POST /users → returns /users/42). Use PUT when the client knows the ID, POST otherwise.