The Verb Comes First
An HTTP request begins with a line like GET /guides/ HTTP/1.1. The first word is the method — the verb describing the action; the second is the path to the resource. Together they answer "what do you want to do, and to what?" The body, if there is one, and the headers fill in the details, but the method sets the intent. The server reads it and decides how to respond, returning a status code that reports how it went.
There are nine standardised methods, but in practice four do almost all the work — GET, POST, PUT, and DELETE — and they map neatly onto the four things you can do with stored data: read, create, update, and remove. This pairing is the backbone of REST and of nearly every web API you will ever touch.
The Methods, One by One
| Method | Purpose | Has body? |
|---|---|---|
GET | Retrieve a resource. The workhorse — every page and image you load is a GET. | No |
POST | Submit data to create a resource or trigger an action (a form, a new comment, a payment). | Yes |
PUT | Replace a resource entirely with the version you send. | Yes |
PATCH | Apply a partial update — change only the fields you include. | Yes |
DELETE | Remove a resource. | Usually no |
HEAD | Like GET but returns only headers, no body — used to check a resource cheaply. | No |
OPTIONS | Ask the server which methods a resource supports; the basis of CORS preflight. | No |
CONNECT | Establish a tunnel through a proxy, typically for HTTPS. | No |
TRACE | Echo the request back for diagnostics; usually disabled for security. | No |
GET vs POST: The One Distinction Everyone Hits First
The split that matters most in everyday web work is GET versus POST. A GET asks for something and is expected to leave the server unchanged. Its parameters ride in the URL's query string, so a GET can be bookmarked, shared, cached, and prefetched — and it shows up in browser history and server logs. That is exactly why you must never put a password or a "delete account" action behind a GET: anything in the URL is visible and repeatable.
A POST sends data in the request body to create something or cause an effect. Because it can change state, the browser treats it carefully — try to refresh a page that resulted from a POST and you will see the familiar "resubmit form?" warning, because blindly repeating it might charge a card or post a comment twice. The body also has no practical size limit and is not logged in the URL, which is why forms and file uploads use POST.
Safe and Idempotent: The Rules That Govern Retries
Two properties, defined in the HTTP specification, explain a lot of otherwise mysterious browser and API behaviour.
A method is safe if it only reads and never changes server state. GET, HEAD, and OPTIONS are safe — which is why a browser can prefetch links or a crawler can follow them without consequence. POST, PUT, PATCH, and DELETE are unsafe by design: they exist to change things.
A method is idempotent if making the same request many times has the same end result as making it once. This is subtler than "safe," and it is the property that makes automatic retries possible:
| Method | Safe | Idempotent |
|---|---|---|
GET / HEAD | Yes | Yes |
PUT | No | Yes |
DELETE | No | Yes |
POST | No | No |
PATCH | No | Not guaranteed |
DELETE is the clearest illustration: deleting a record once or five times leaves the same outcome — gone. So if a DELETE request times out, a client can safely resend it. POST is the opposite: each one usually creates a new record, so resending after a timeout risks a duplicate. This is precisely why a connection blip during checkout can produce a double order, and why well-designed APIs add an idempotency key to make even POST safe to retry.
PUT vs PATCH, and Why HEAD Is Underrated
PUT and PATCH both update, but differently. PUT says "here is the complete new version of this resource" — anything you leave out is treated as cleared. PATCH says "change just these fields and leave the rest alone." Send a PUT with only a user's email and you may wipe their name; send a PATCH and you only touch the email. The rule of thumb: PUT to overwrite the whole thing, PATCH to nudge a few fields.
HEAD rarely gets attention but solves a real problem: it returns exactly the headers a GET would, with no body. A link checker can confirm a page exists, a download manager can read Content-Length to plan a resumable transfer, and a cache can check whether content changed — all without paying to download the payload. OPTIONS, meanwhile, is mostly invisible to users but central to the web's security model: before a browser makes certain cross-site requests it sends an automatic OPTIONS "preflight" to ask permission, the mechanism at the heart of CORS.
Frequently Asked Questions
What is the difference between GET and POST?
GET retrieves a resource and should not change anything; its parameters sit in the URL, so it can be cached and bookmarked. POST sends data in the body to create something or trigger an action. Because POST changes state, browsers warn before resubmitting it, whereas a GET can be repeated freely.
What does idempotent mean in HTTP?
An idempotent method produces the same end result whether you send it once or many times. GET, PUT, and DELETE are idempotent; POST is not. Idempotency is what makes it safe for a client to retry a request after a network error.
What is the difference between PUT and PATCH?
PUT replaces an entire resource with the version you send — omitted fields are treated as cleared. PATCH applies a partial update, changing only the fields you include. Use PUT to overwrite a whole record and PATCH to adjust a few fields.
What is the HEAD method used for?
HEAD returns the same headers a GET would, but no body. It is used to check whether a resource exists, how big it is, or whether it has changed — without the cost of downloading the content.
Which HTTP methods are safe?
GET, HEAD, and OPTIONS are safe because they are read-only and change nothing on the server, so they can be prefetched and retried freely. POST, PUT, PATCH, and DELETE are unsafe because they are meant to modify state.