A REST API is like a set of driving rules for software. Because the rules are standardized, everyone knows to stop when they see a red octagon.
So what are the rules of a REST API?
Every request has two parts: an HTTP method and a URL.
GET /pos/123
Here, GET is the method and /pos/123 is the URL. The method says what to do, and the URL identifies which thing you’re doing it to, e. g., get PO 123.
Each object, meaning a single record or item the system stores (a purchase order, a supplier, a line item), gets its own address: /pos is the collection of all purchase orders, and /pos/123 is one specific PO. The method works like a verb: GET reads, POST creates, PATCH updates, and DELETE removes. So DELETE /pos/123 reads almost like a sentence: delete PO 123.
For software, the benefit of REST is predictability. Non-REST APIs often send everything as a POST and invent their own action names, like /getPO or /removeOrder, which is like every city making up its own traffic rules. Each one has to be learned from scratch. With REST, GET always means read and DELETE always means delete, so developers and tools understand an API’s behavior without digging through custom documentation. Unlike driving rules, driving etiquette takes on more nuance. Similarly, REST is a convention rather than a strict law, so some APIs follow it more loosely than others.
Here’s what a real request looks like.
Request
POST /pos Host: api.example.com Authorization: Bearer abc123token Content-Type: application/json { "supplier_id": 45, "ship_date": "2026-10-15", "line_items": [ { "sku": "BOLT-10", "qty": 500, "unit_price": 0.12 } ] }
Response
201 Created { "id": 123, "status": "open", "supplier_id": 45, "ship_date": "2026-10-15" }
To create a purchase order, you’d send POST /pos with an authorization token proving who you are and a JSON body containing the PO details: supplier, ship date, and line items. The server replies with a status code (201 Created means it worked) and returns the new PO with its ID. From then on, that PO has its own address, /pos/123, and anyone can read, update, or delete it using the same simple pattern.
Fun fact: REST is an acronym for REpresentational State Transfer. When you request a resource, the server sends back a representation of its current state (like the PO’s JSON data), and that representation is transferred between systems.
