Every solid API starts with a mental shift: stop thinking about functions to call and start thinking about resources to expose. A resource is any concept your system tracks — a customer, an order, a report — and REST organizes your whole interface around them.
Resources Are Nouns
A RESTful design names things rather than actions. Instead of endpoints like fetchCustomerData or runInvoiceUpdate, you expose collections such as customers and invoices, and individual items within them. Consumers then apply a small, predictable set of operations to those nouns. This naming discipline is the single biggest factor in whether an API feels intuitive to a stranger reading it for the first time.
Representations Travel Over the Wire
Clients never touch the resource itself; they exchange representations of it, most commonly JSON documents. The same order resource might be represented differently for a mobile app than for an internal reporting tool. Separating the stored thing from its transmitted form gives you freedom to evolve storage without breaking consumers.
Statelessness and Its Payoff
Each request must carry everything the server needs — identity, parameters, context — because REST servers keep no memory of previous calls. That constraint feels restrictive at first, yet it is exactly what allows any server behind a load balancer to answer any request, making horizontal scaling and caching straightforward.
Action Step
Choose a familiar business domain, such as a bookstore or gym. List eight resources it contains, mark which are collections and which are single items, and sketch the JSON representation you would return for two of them. Keep this sketch — later lessons build on it.
Educational content only. Technologies and best practices evolve — verify against current official documentation. This course does not certify anyone.