HTTP Method

While the web only handed back documents, there was nothing to distinguish. You gave an address over HyperText Transfer Protocol (HTTP), the rules browsers and servers use to talk, and the document at that address came back. Screens that collected input and sent it to a server changed that. Early on, teams encoded the action in the address itself: /getPost to read, /deletePost to remove. The conventions were local, so one team wrote /removePost and another wrote /post_delete, and connecting to someone else's endpoint meant reading their documentation end to end.

A second problem sat underneath that one. A request passes through machinery that stores responses for reuse, and that machinery does not open request bodies. With the action buried in a naming convention, it had no basis for deciding what was safe to store or replay. Re-sending a read costs nothing; re-sending a payment charges twice. From the outside the two looked identical.

The HTTP method pulls that basis to the front of the request. A verb rides alongside the address, so anyone handling the request knows what it will do without opening it.

It solves the problem of not knowing a request's intent until you read it. Against a single address like /documents/34, the verb is what separates a read from an edit from a deletion.

Five verbs cover almost everything.

1. GET — fetch. Give me the contents of document 34. Nothing changes on the server.
2. POST — create. Send a title and body, and the server assigns the new document a number and returns it.
3. PUT — replace whole. Overwrite document 34 with what's being sent now; fields you omit come out empty.
4. PATCH — replace part. Change the title of document 34 and leave the rest alone.
5. DELETE — remove. Take document 34 away.

Reading these as labels is reading half of it. Each verb carries a promise, and the machinery along the path acts on that promise. There are two promises.

The first is whether the server changes. GET is defined as a verb that doesn't, which is why caching — storing a response and serving it again from the store — applies to GET and not to the others.

The second is whether repeating the request changes the outcome, which is idempotency. Send "delete 34" three times and you still end at one deleted document, so DELETE is idempotent. Send a POST three times and you get three documents. Whether a client can simply re-fire a request after a dropped connection is decided right here. Payments, which have no choice but to be POST, carry an extra value marking the request as one and the same, so a retry lands as a duplicate instead of a second charge.

Building endpoints without methods is a real practice. What you give up is the judgment the machinery along the path used to make for you.

The first alternative puts the action in the address. It's the old approach, and it still earns its place between internal services, especially when an action doesn't reduce cleanly to read, write, or remove. Handing a document to another team is just /transferOwnership — no argument about which verb fits. The cost is that endpoints multiply with features, and nothing in between ever knows what a call does.

The second sends everything one way. GraphQL, where callers name the exact fields they want, is close to this: reads and writes all travel as POST, and the query in the body decides what happens. Fetching one screen's worth of data in a single round trip is worth a lot, but since every request looks the same from outside, HTTP-level caching is off the table.

The third is a compromise: use only GET and POST and handle the rest inside POST bodies. Web frameworks still ship a workaround that sends the real verb as a hidden value for environments that block the other methods.

All three work. An endpoint you open to outsiders is a different matter. Someone seeing it for the first time should be able to guess what a call does from the address and the verb alone, which is much of why REST, the style that treats each resource as an address, spread as far as it did.

"Don't put that behind a GET. Just calling it changes state."

A verb that's supposed to be read-only is doing work, which means any tool that walks links can cause damage.

"No response came back — is it safe to retry? If it's a PUT, just fire it again."

The verb is idempotent, so a duplicate arrival doesn't change the result.

"Why is the list query a POST?"

Usually because the filter conditions are too long for an address, and a rule broken knowingly sometimes gets left alone.

Early on at Pagedeck, the delete button in the document list was an ordinary link. It was a GET request to a delete address, and for six months nothing went wrong. The damage came when an internal browser tool turned on a feature that pre-opens the links on a page. Nobody clicked anything and thirty documents disappeared. Theo moved deletion to DELETE, and since then new endpoints at Pagedeck get their verb decided before their address, because once the verb is settled what comes back as a status code mostly follows.

The most common misreading treats the difference as mechanical. People learn first that GET puts values in the address and POST puts them in the body, which is true and leaves out the part that matters. The real difference is a promise. The agreement that everyone can trust this verb not to change the server is the substance; where the values ride is a consequence of it. Get that backwards and you'll build a read as a POST without seeing the problem. The back button throws a resubmission warning every time, the address can't be copied and shared, and nothing caches, so the server recomputes the same list on every call.

A second mistake is treating the right verb as a safety measure. Naming an operation DELETE makes it feel protected, but a method announces intent and enforces nothing. Anyone can send a request that imitates the same address and verb. Unless authorization — checking what this caller is allowed to do — runs inside the server, one DELETE carrying someone else's document number erases someone else's work.