Chapter 1 of 8 · 4 practices · 3 min · 4-question quiz
Resources and URLs
How to model an API as resources and name their URLs so they stay predictable as the API grows.
Start: Model resources as nouns and let the method be the verb4 practices in this chapter
- 1Model resources as nouns and let the method be the verbIn HTTP, the method already says what to do. The URL should say what to do it to. URLs like
/getOrders,/createOrderand/deleteOrder?id=7duplicate the method in the path and leave clients… - 2Nest only for real ownership, and keep it to one levelNesting expresses that a resource belongs to another:
/orders/7/itemsare the items of order 7. It stops helping after one level./customers/3/orders/7/items/12/discountsforces clients to know… - 3Model operations that are not CRUD as sub-resources or state changesSome operations do not map neatly onto create, read, update and delete: cancelling an order, refunding a payment, resending an email. Two patterns keep them RESTful without inventing verbs in every…
- 4Use stable, opaque identifiers, and keep secrets out of URLsResource ids end up in client databases, logs and bookmarks, so they must never change. Treat them as opaque strings in the contract, even if they are numbers today, so you can change how they are…
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.