HTTP Methods Explained

Methods are verbs

If a URL is the noun — the thing you are acting on — then the HTTP method is the verb that says what to do with it. REST keeps the set of verbs small and well-defined on purpose, so that any developer can guess what an endpoint does from the method alone before reading a word of documentation.

The five you will use most are GET to read, POST to create, PUT to replace, PATCH to partially update, and DELETE to remove. There are others, such as HEAD for headers-only requests and OPTIONS for capability discovery, but those five cover almost everything you will write day to day. Learning what each one promises, and what it does not, is most of what you need to use any REST API correctly and confidently.

Reading with GET

GET retrieves a representation of a resource and must never change anything on the server. It is described as a safe method: calling it once, or a thousand times, leaves the world exactly as it was. Any filtering, sorting, or paging you need is expressed in the query string of the URL, never in a request body.

Because GET is safe, browsers, proxies, and caches feel entitled to repeat it, prefetch it, or store its result for reuse. That is precisely why hiding a side effect behind a GET — say, deleting a record when a link is merely fetched — is such a serious bug: some intermediary may trigger it without anyone intending to. Reserve all writes for the methods that were designed to carry them, and keep GET strictly for reading.

Writing with POST, PUT, and PATCH

POST typically creates a new resource or triggers an action, and the server usually assigns the new identifier and returns it to you. PUT replaces a resource entirely with the representation you send, which means any field you omit is treated as cleared rather than left alone. PATCH applies a partial change, updating only the fields you actually include in the body.

Choosing correctly between them matters more than it first appears. Sending a partial body with PUT can silently wipe data you never meant to touch, whereas PATCH is the safer choice for targeted edits to a few fields. When in doubt, check what the endpoint documents — the same path may legitimately accept several methods, each with different semantics and expectations about the body you provide.

Idempotency and safety

An idempotent method produces the same end state whether you send the request once or repeat it many times. GET, PUT, and DELETE are idempotent; POST generally is not, because each call may create yet another record. Consider deleting the same resource twice:

DELETE /v1/widgets/42   then again   DELETE /v1/widgets/42

The first request removes the widget; the second simply confirms it is already gone, leaving the end state unchanged. This property is exactly what makes safe automatic retries possible after a dropped connection or an ambiguous timeout — a topic worth pairing with idempotency keys when a write is not naturally idempotent. Knowing which methods give you this guarantee for free shapes how aggressively you can retry.

Picking the right verb

A simple rule of thumb covers most cases: read with GET, create with POST, replace with PUT, tweak with PATCH, and remove with DELETE. Matching your intent to the method keeps an integration predictable and lets infrastructure — caches, proxies, retry layers — make the right optimisations on your behalf rather than guessing.

Treat the method as a promise about behaviour, not just a label, and your code will be easier for the next person to follow. For the failure-handling side of repeated writes, and how to retry a create without duplicating it, read idempotency keys next, since that is where the safe-retry story becomes practical.