Design a resource API for managing bookings: which method-and-URL pairs cover creating, changing, cancelling, listing, and inspecting a booking?
One resource URL, five operations: POST /bookings/ creates, PUT /bookings/<id> changes, DELETE /bookings/<id> cancels, GET /bookings/ lists (filtered via query parameters), and GET /bookings/<id> shows one.
* Two URLs and four verbs cover the whole booking lifecycle - the method carries the action. *
The whole API hangs off a single resource collection, e.g. https://example.com/bookings/:
| Operation | Request | Note |
|---|---|---|
| Reserve | POST /bookings/ |
the response returns the new booking's <id> |
| Change a reservation | PUT /bookings/<id> |
body carries the new values (e.g. a new date) |
| Cancel | DELETE /bookings/<id> |
no body needed - the URL says which one |
| List / search | GET /bookings/ |
filters go in query parameters: ?available=true&from=2026-01-01&to=2026-01-31 |
| Details of one | GET /bookings/<id> |
Two patterns worth noticing: the <id> the client uses everywhere comes from the server - it is handed back by the initial POST, so the client never invents identifiers - and searching is not a separate endpoint: it is a GET on the collection with query parameters narrowing the result. Every future resource (users, rooms, invoices) can copy this exact scheme, which is what makes a resource API predictable.