HTTP Method

TL;DR: The HTTP method is the verb in a request (GET, POST, PUT, PATCH, DELETE) that tells the server what to do with the resource the URL points at. Method names are case-sensitive, and the method decides whether a request is safe to retry or cache.

Why Method Choice Matters

Clients and caches act on the method. If a response gets lost, a client can retry an idempotent request like PUT, but can’t assume repeating a POST is harmless. Caches check the method before storing or reusing a response.

RFC 9110 §9.1 makes method names case-sensitive, and the standard ones are uppercase. To HTTP, PATCH and patch are two different methods.

The Methods Most Developers Meet First

Method	Requested operation
GET	Retrieve a representation.
HEAD	Retrieve its metadata without response content.
POST	Process submitted content under the target’s rules.
PUT	Create or replace state at the target URL.
PATCH	Apply a change document.
DELETE	Remove the resource at the URL.
OPTIONS	Describe communication options.

POST isn’t only for creating things; it covers any processing the endpoint defines. PUT can create a resource as well as replace one. What PATCH does depends on the patch format the endpoint accepts.

A Simple Example

Here’s the same URL with two different methods, against an example API:

curl -i 'https://api.example.com/documents/notes'
curl -i -X DELETE 'https://api.example.com/documents/notes'

And a partial update on that URL, if the API accepts JSON Merge Patch:

curl -i -X PATCH 'https://api.example.com/documents/notes' \
  -H 'Content-Type: application/merge-patch+json' \
  --data '{"title":"Reviewed notes"}'

The URL never changes. Only the method does, and that changes what you’re asking the server to do, assuming the endpoint supports it.

Safe And Idempotent Are Different

A safe method asks for no state change, though the server might still log it. GET, HEAD, OPTIONS, and TRACE are safe. PUT and DELETE aren’t safe, but they are idempotent: repeat the same request and you end up in the same state. The responses can still differ.

POST and PATCH aren’t idempotent in general, though you can design a specific operation to be.

The Common Real-World Mistake

The classic mistake is putting a change behind a GET, like GET /documents/notes?delete=true. Crawlers and prefetchers follow GET links freely, so one can delete your data without anyone clicking. Use DELETE or POST.

If the server knows the method but the resource doesn’t support it, return 405 with an Allow header listing what is supported; Allow is required there. For a method the server doesn’t recognize or implement at all, return 501. And listing a method in an OPTIONS response isn’t permission to use it; check authorization on the real request.

Related

• Idempotent
• HTTP Request