Verbs That Mean Something
Two pages ago, the request line started with a verb: GET. HTTP has a small set of these verbs — the official word is methods — and APIs use them with real intent. GET reads. POST creates. PUT and PATCH change. DELETE removes. They are not five spellings of "do it"; they are promises about consequences.
The difference sounds academic until the day a request times out and your finger hovers over "try again." Whether pressing it is harmless or books two bikes depends entirely on which verb you sent. That day comes in Chapter 7 — this page is where you become the kind of person who is ready for it.
| Verb | What it means | Changes something? | Safe to repeat? |
|---|---|---|---|
GET | read — give me this | no | yes, endlessly |
POST | create — make a new thing | yes | no — twice makes two |
PUT | replace (or create) — set it to exactly this | yes | yes — same result again |
PATCH | edit — change these fields | yes | depends on the edit |
DELETE | remove it | yes | yes — it stays gone |
GET: Look, Don't Touch
GET means "give me this, and change nothing." Asking for /v1/stations a hundred times leaves the world exactly as it was — same stations, same data, no side effects. The official word for this property is safe: a GET makes no changes on the server, by contract. That guarantee is why a browser will happily re-request a page, and why every tool treats GET as the verb you can experiment with freely. Everything you send in this book before Chapter 3's last page is a GET, for exactly that reason.
POST: Make a New Thing
POST means "here is something new — act on it, create from it." POSTing a reservation to Tandem starts a reservation existing. And here is the sentence to underline: do it twice, and two exist. POST is the verb that books, bills, registers, and sends — the verb with consequences. Nothing about it is dangerous when used deliberately; the danger is only ever in repeating it carelessly, and Chapter 7 builds the full discipline for exactly that moment.
PUT, PATCH, DELETE: Change and Remove
The remaining three you will mostly meet in documentation rather than type daily, so meet them as vocabulary. PUT replaces a thing wholesale — "set station st_014's record to exactly this" — and at a known address it may also create it. PATCH edits in place: "change just the capacity field" — and whether a repeat is harmless depends on the edit: "set capacity to 24" repeats safely, "add one bike" does not, so check the documentation before any retry. DELETE removes. Notice something useful about PUT and DELETE: repeating them is boring, in the good way. Setting a record to the same value twice leaves one value; deleting the already-deleted leaves it deleted. Repetition without accumulation — the property POST conspicuously lacks, and the reason the verb table's last column is the one worth memorizing.
The Verb Is Half the Sentence
One more habit before the chapter's finale. An API's documentation describes every operation as verb plus path: GET /stations lists them, POST /rides starts one. Same path, opposite acts — the pair means nothing without the verb. And the small print underneath: the verb states the intent, but the API's documentation states the actual promise. Well-behaved APIs honor the meanings on this page; the occasional odd one bends them, and the documentation is where bends are confessed. Read the sentence whole: verb, path, promise.
- "The verb is decoration; the URL does the real work."
GET /ridesandPOST /ridesare opposite acts on the same address — one lists rides, one starts a ride. The pair means nothing without the verb. - "POST is just how you send bigger requests." POST's meaning is create and act, not "GET with a body." Using it changes things, and often costs money — that is its job.
- "Safe means secure." Safe is a technical promise about side effects — a GET changes nothing on the server. It says nothing about privacy or encryption; that is the scheme's department.
- "Repeating any request is equally risky." The verbs split cleanly: GET, PUT, and DELETE repeat without accumulating; POST accumulates. That split is the whole retry question, three chapters early.
- "Can I repeat this without consequences?" is answered by the verb — the single most practical fact to hold when a request times out and the retry button beckons. Chapter 7 builds its whole discipline on it.
- Documentation is organized verb-first. Reading POST /rides as a sentence — create a ride, here — is reading the API's floor plan fluently, which is most of what "knowing an API" means day to day.
Knowledge Check
What happens if the same POST request is sent twice?
- The server notices the duplicate all on its own and quietly ignores the second one
- Two things are created: two reservations, two orders, two of whatever it makes
- The second request is rejected as invalid and returns an error
- The second one simply replaces the first, leaving a single updated thing behind
What does it mean that GET is a "safe" method?
- GET requests are always encrypted on the road, so they cannot be read in transit
- GET requests never fail, because they only ask for existing data
- A GET changes nothing on the server, no matter how many times you send it
- The server always checks your permissions and identity before answering a GET
Why do the docs describe operations as verb plus path, like POST /rides?
- Because the same path does opposite things under different verbs
- Because it is a naming convention that makes documentation look consistent
- Because each verb is handled by a different server behind the API
- Because the path is what matters and the verb is a required formality
Which verbs can be repeated without their effect accumulating?
- POST and PATCH — creating and editing are both friendly to being repeated
- GET and POST — reading and creating leave the server unchanged
- GET, PUT, and DELETE — repeating them lands on the same result
- All of them except DELETE, which removes more each time
You got correct