HTTP methods

The method (sometimes called the verb) tells the server what kind of action you want.

• GET retrieves a resource.
• POST submits data or triggers an action.
• PUT replaces a resource entirely.
• PATCH updates part of a resource.
• DELETE removes a resource.
• HEAD is like GET, but the response has no body.
• OPTIONS asks which methods and headers the server allows.

For a notes API, the paths often line up like this:

GET /notes
POST /notes
GET /notes/42
PATCH /notes/42
DELETE /notes/42

Same path, different method, different meaning. That is REST-style routing in a nutshell.

HTTP does not enforce these meanings in code. Nothing stops a server from deleting data on GET. But if you do that, caches, crawlers, and prefetching browsers may destroy data you did not intend to touch. Follow the conventions so the whole ecosystem behaves predictably.

Test methods with curl against a public echo service:

curl -i -X GET https://httpbin.org/get
curl -i -X POST https://httpbin.org/post -d 'title=Learn+HTTP'
curl -i -X DELETE https://httpbin.org/delete

Each response includes a JSON field "method" showing what the server received. You should see GET, POST, and DELETE respectively, all with 200 status codes from httpbin.

HEAD is useful when you only care about headers (last-modified time, content length) without downloading a large file:

curl -I https://flaviocopes.com/rss.xml

That sends HEAD and prints response headers only. Notice there is no RSS body in the output.

Browsers pick methods for you when you click links (GET) or submit forms (POST). APIs expose the choice explicitly. Document which methods each route accepts so client authors do not guess.

Try this on your own project: list your API routes and write the method next to each path. If two routes share a path, make sure the methods express different intents.