Hi friends! Today we're going to order a pizza — and by the time it arrives, you'll understand REST APIs well enough to explain them to someone else. Deal?
An API is a menu and a counter
When you walk into a pizza shop, you don't wander into the kitchen, open the fridge, and start assembling your own dinner. There's a menu that tells you what you can ask for, and a counter where you place your order. The kitchen stays hidden — and that's a feature, not a limitation.
An API (Application Programming Interface) is exactly that: a menu plus a counter for software. One program (the client — your app, your browser) asks for things; another program (the server — the kitchen) does the work and hands back a result. REST is simply the most popular set of house rules for how that counter operates, built on top of plain HTTP.
Resources are nouns
In REST, everything you can ask about is a resource, and every resource has its own URL. Resources are named with nouns, usually plural:
/pizzas— the whole menu of pizzas./orders— all the orders in the system./orders/42— one specific order: yours, number 42.
Notice there's no /getOrder or /makeNewPizzaPlease. The URL names
the thing; a separate piece — the method — names the action.
The four everyday methods
HTTP gives us a small set of verbs, and each one maps neatly onto something you'd do at the counter:
| Method | At the shop | In API terms |
|---|---|---|
GET |
Browse the menu, check on your order | Read data — never changes anything |
POST |
Place a new order | Create a new resource |
PUT / PATCH |
Change your order ("make it a large, add olives") | Update a resource (fully / partially) |
DELETE |
Cancel your order | Remove a resource |
Put a verb and a noun together and you can read API calls like sentences:
GET /pizzas means "show me the menu," and DELETE /orders/42 means
"cancel order 42." Isn't that pleasantly boring? Boring is good in an API.
Status codes are the shop's replies
Every request gets an answer, and the answer always starts with a status code — a three-digit summary of how things went:
| Code | Meaning | The shop says |
|---|---|---|
200 | OK | "Here you go!" |
201 | Created | "Order placed — you're number 42." |
400 | Bad Request | "Sorry, 'a pizza with no size' doesn't make sense." |
404 | Not Found | "We have no order 999 here." |
500 | Server Error | "The oven caught fire — it's us, not you." |
Tip: The first digit tells you who to blame. 2xx means
success, 4xx means the client asked wrong, and 5xx
means the server messed up. That one habit will speed up your debugging forever.
What a response actually looks like
So what comes back when you check on your order? Almost always JSON — a
simple text format for structured data. Here's GET /orders/42:
{
"id": 42,
"status": "baking",
"pizzas": [
{ "name": "Margherita", "size": "large" }
],
"totalPrice": 12.50,
"delivery": true
}Readable by humans, parseable by every programming language on earth. That combination is why REST plus JSON took over the world.
One last idea: stateless
REST APIs are stateless: the shop doesn't remember you between calls. Every request must carry everything the server needs — which is why you quote your order number each time instead of saying "how's my pizza doing?" and hoping they recognize your voice. It sounds cold, but it's what lets one little shop scale into a thousand identical counters serving millions of customers.
Note: When apps need to "stay logged in," they include a token with every request — like showing your receipt each visit. The server still remembers nothing; the receipt carries the memory.
That's the whole core of REST: nouns for resources, verbs for actions, codes for outcomes, and no memory between calls. You'll see this pattern everywhere now. As a next step, get comfortable reading those responses with JSON explained for beginners — and when you're curious how REST compares to the alternatives, try REST vs GraphQL vs gRPC.