HTTP request methods

When your browser sends an HTTP request, the very first word says what you want to do, not just what you want. That word is the request method. It is the verb of the sentence: the URL names a thing (a noun), and the method says the action. "GET /photos/cat.jpg" means "give me the cat photo"; "DELETE /photos/cat.jpg" means "remove the cat photo." Same resource, opposite intentions, distinguished entirely by the method.

The four you meet most often each have a clear job. GET retrieves a resource and should not change anything on the server — it is meant to be a pure read. POST sends data to the server to create something or trigger an action, like submitting a form or posting a comment; it is the default for "do something with this data." PUT places or replaces a resource at a known location with the data you send. DELETE removes the named resource. Two properties matter: GET, PUT, and DELETE are meant to be idempotent — doing them once or ten times leaves the same end state — while POST generally is not, which is why a browser warns before resending a POST.

These methods are a shared agreement, not magic. The server is free to interpret them, but well-behaved web services follow the conventions because the whole ecosystem (caches, proxies, search-engine crawlers) relies on them. A crawler will happily issue GET requests because GET promises not to change things, but it will never issue a DELETE. This is also the backbone of REST APIs, where GET/POST/PUT/DELETE map cleanly onto read/create/update/remove operations on data.