Theory
The style most APIs follow
When your app calls a web service, that service almost always follows a particular style: REST. Understanding REST means you can predict how to use nearly any API you meet, because they share the same conventions.
You saw REST from the server side when building the Express backend; here you meet it as a consumer, the app calling the API. This lesson lays out REST's core ideas, resources, methods, statelessness, JSON, so that reading an API's documentation and calling it correctly becomes second nature. REST is the lingua franca of web APIs.
At a glance
| Principle | What it means |
|---|---|
| Resources as URLs | Each thing has a URL: /events, /events/5 |
| Methods as actions | GET reads, POST creates, PUT updates, DELETE removes |
| Stateless | Each request carries all it needs; the server keeps no session between requests |
| JSON data | Requests and responses typically exchange JSON |
| Status codes | Responses report outcome: 200 OK, 404 Not Found, and more |
Theory
Resources, methods, and JSON
In REST, a URL names a resource (a thing): /events is the collection of events, /events/5 is event 5. The HTTP method says what to do with it: GET to read, POST to create, PUT to update, DELETE to remove, the same nouns-in-the-URL, verbs-in-the-method idea you saw on the backend.
Data travels as JSON both ways, and each response carries a status code (200 for success, 404 for not found, and so on). So to fetch FestConnect's events from a REST API, your app sends a GET to the /events endpoint and parses the JSON list it gets back. Predictable and uniform, whatever the server.
Formula
Stateless: every request stands alone
A defining REST principle is statelessness: each request must carry everything the server needs to handle it, because the server does not remember anything about your app between requests, there is no server-side session tying requests together.
So if a request needs to know who you are, it includes your auth token every time; the server does not 'remember' you from the last call. This makes REST APIs simple and scalable (any server can handle any request, since none rely on stored client state). For your app, it means: include what each request needs, do not assume the server recalls the previous one.
Quiz
To read the list of events from a REST API at the /events endpoint, which HTTP method does your app use?
- POST, because it is powerful
- GET, because GET reads (retrieves) a resource in REST
- DELETE, because it fetches data
- There is no method; you just open the URL in a browser
Show the answer
GET, because GET reads (retrieves) a resource in REST
In REST, GET is the method for reading (retrieving) a resource, so fetching the events list is a GET request to /events. Option A is wrong: POST is for CREATING a new resource (like adding an event), not reading; using POST to read violates REST conventions. Option C is wrong: DELETE removes a resource, the opposite of reading it. Option D misunderstands the mechanism: while a GET is indeed what a browser does when you open a URL, your APP performs the GET programmatically (via a library like Volley) to receive JSON, not a rendered page. Match the method to the action: GET to read, POST to create, PUT to update, DELETE to remove.
Think first
Why is statelessness good for scaling an API?
REST servers keep no memory of your app between requests. Why is that a strength rather than a limitation? Then tap.
Show the answer
Because when each request is SELF-CONTAINED and the server stores no per-client session, ANY server can handle ANY request, which makes the system far easier to scale and more robust. Imagine a popular API served by many identical server machines behind a load balancer. If the servers had to REMEMBER things about each client between requests (a stateful session), then your app's follow-up requests would have to keep going back to the SAME server that holds your session, or that state would have to be shared and synchronised across all servers, both of which are complicated, limiting, and fragile (if that server crashes, your session is lost). With STATELESS REST, every request carries everything the server needs (including who you are, via a token), so it does not matter which server handles it, requests can be freely spread across as many machines as you like, and you can add more servers to handle more load without worrying about session affinity. It also makes servers simpler (no session store to manage) and more resilient (a server failing does not lose client state, since there is none to lose). The cost is that each request must re-send some information (like the auth token) rather than relying on the server to remember, a small overhead in exchange for big gains in scalability and reliability. This is a major reason REST became the dominant API style for the web: statelessness lets APIs scale horizontally with ease. No stored session means any server can serve any request, which is exactly what large-scale systems need.
Summary
Key takeaways
- REST (Representational State Transfer) is the dominant architectural style for web APIs.
- Resources are identified by URLs (/events, /events/5); HTTP methods express actions (GET, POST, PUT, DELETE).
- REST is stateless: each request carries all it needs, and the server keeps no client session between requests.
- Data is typically exchanged as JSON, and responses carry status codes (200 OK, 404 Not Found).
- From the consumer side, fetching events is a GET to /events, then parsing the JSON returned.
- Statelessness lets any server handle any request, making REST APIs simple to scale and resilient.
- Memory hook: resources in URLs, actions in methods, stateless requests, JSON data, status codes.