HTTP Methods Table
| Method | Typical use | Key trait |
|---|---|---|
| GET | Fetch a resource | safe, idempotent, cacheable |
| HEAD | GET without the body | safe, idempotent, cacheable |
| OPTIONS | Ask what the endpoint allows | safe, drives CORS preflight |
| POST | Create; submit data | neither safe nor idempotent - doubles create doubles orders |
| PUT | Replace a resource wholesale | idempotent - same request, same end state |
| PATCH | Modify part of a resource | not guaranteed idempotent - depends on the patch |
| DELETE | Remove a resource | idempotent - deleting twice changes nothing more |
| CONNECT | Tunnel through a proxy | the method HTTPS proxies speak |
| TRACE | Loop the request back | often disabled - leaks cookies and auth headers |
Nine HTTP request methods cover virtually every API call ever made - and their contracts (safe? idempotent? cacheable?) decide retry logic, caching layers and CORS preflights. This table carries all nine verbatim from MDN with the property flags that make the differences mechanical.
The arguments end here: the client chooses the resource ID means PUT, the server issues it means POST; retry anything idempotent, never blind-retry a POST.
How to use
- Filter by property - safe, idempotent, cacheable - to see which methods survive retries and proxies.
- Click a method name to copy it into a doc, an annotation or an API spec.
- Check the CONNECT and TRACE rows for the two methods you will rarely implement but should recognize in logs.
Frequently asked questions
Why is PUT idempotent but POST not?
PUT replaces the resource at a URL you choose - repeating it lands the same state. POST tells the server to do something, and doing it twice usually means two records or two charged cards. That asymmetry is why payment APIs accept POST but wrap it with client-side idempotency keys.
What makes a method safe?
Safe methods (GET, HEAD, OPTIONS) never change server state - they are read-only, which is why crawlers may follow them freely and proxies may cache them. PUT and DELETE change state, so they are unsafe even though they are idempotent; the two properties are independent.
What is CORS preflight?
Before certain cross-origin requests, the browser automatically sends an OPTIONS request asking whether the real request is allowed - carrying Access-Control-Request-Method headers. If the server answers wrong, the real request never fires; debugging CORS means debugging an OPTIONS you never wrote.
Is PATCH idempotent like PUT?
Not guaranteed - PATCH applies an instruction, and instructions can stack: {"op":"increment"} changes the resource twice when sent twice. A PATCH that sets absolute values behaves idempotently, but the spec leaves it to the patch format, so retry logic treats PATCH as carefully as POST.