HTTP methods — the verbs at the start of every request — tell a server what you want to do. Using them correctly makes an API predictable and lets the whole web infrastructure of caches and proxies work with you rather than against you. This guide covers each method and the two properties that matter most: safety and idempotency.
The core methods
- GET — retrieve a resource. Should never change anything.
- POST — create a new resource or trigger an action.
- PUT — replace a resource entirely with the provided representation.
- PATCH — apply a partial update to a resource.
- DELETE — remove a resource.
Safe methods
A method is "safe" if it does not modify server state. GET and HEAD are safe — they only read. This is why crawlers freely follow GET links but never POST. Building anything that changes data behind a GET request breaks this contract and causes real bugs, like a crawler accidentally deleting records by visiting links.
Idempotent methods
A method is idempotent if making the same request multiple times has the same effect as making it once. GET, PUT and DELETE are idempotent: deleting a resource twice leaves it deleted. POST is not idempotent — submitting it twice typically creates two resources, which is why double-clicking a submit button can produce duplicate orders. Understanding this guides retry logic and form handling.
PUT vs PATCH
Both update a resource, but differently. PUT replaces the whole resource, so you send the complete representation. PATCH changes only the fields you include. If you PUT a partial object, the missing fields may be wiped; PATCH avoids that by design. Choose based on whether you are replacing or amending.
Why it matters
Honouring method semantics is not pedantry — it is what lets caching, retries, prefetching and crawling behave correctly. An API that uses the right verbs is one that the rest of the web can reason about safely.