Class Notes: Introduction to REST
1. Core Definition
- Acronym: REST stands for Representational State Transfer.
- What it is: REST is an architectural style or design pattern used for exchanging messages between two systems over the web.
- Origin: Proposed by computer scientist Roy Fielding in his academic thesis. It describes how network resources should be defined and addressed.
Key Takeaway: REST is a design pattern, not a strict protocol.
2. Protocol vs. Design Pattern
To understand REST, it is crucial to understand the difference between a protocol and a design pattern:
- Protocol (Strict Rules): Think of a 3-pin plug and socket. The plug is designed to fit only one specific way. If you change the socket, the plug won’t fit, and it fails to work.
- Design Pattern (Guidelines): Think of a house floor plan. It provides a set of guidelines. You can choose to follow specific parts of the plan, adapt others, and still successfully build a house. REST is like the house plan.
3. The 6 Principles of REST
Roy Fielding outlined six specific design patterns for REST. If web communication follows these patterns, it is considered “REST-based”:
- Client-Server: The system is divided into clients (which request resources) and servers (which hold resources).
- Stateless: The server does not store any state or session information about the client. Every request from the client is treated as a brand new, independent call.
- Cacheable: The client should be able to cache responses to improve performance and reduce server load.
- Layered System: The architecture can have multiple layers (like load balancers or intermediate servers). The client cannot tell whether it is connected directly to the end server or an intermediary.
- Code on Demand: The server can temporarily extend the client’s functionality by sending executable code (like JavaScript).
- Uniform Interface: There is a standardized, uniform way that messages are packed, identified, and exchanged between the client and server.
4. Real-World Application
- Flexibility: Many services claim to be “RESTful” even if they do not strictly follow all six principles.
- Best Practice: While you do not have to follow every single rule to benefit from REST, adhering to the most important ones ensures your web services function effectively as intended by the architecture.
REST stands for Representational State Transfer. It is not a protocol, a language, or a piece of software. Instead, it is a set of architectural rules and guidelines for building web services. When an API (Application Programming Interface) follows these rules, it is called a RESTful API.
The easiest way to understand REST is to think of a restaurant.
- You (the Client) look at a menu and tell the waiter what you want.
- The waiter (the REST API) takes your order to the kitchen.
- The kitchen (the Server) prepares your food.
- The waiter brings the food (the Response) back to you.
Core Concepts of REST
To use a REST API, you need to understand two foundational concepts: Resources and Endpoints.
- Resource: In REST, everything is treated as a resource. A resource is an object or a representation of something, like a user, a blog post, a photo, or a product in a store.
- Endpoint: Every resource is accessed via a specific URL called an endpoint. For example, if you are building an API for a bookstore, the URL
[https://api.bookstore.com/books](https://api.bookstore.com/books)is the endpoint to access the “books” resource.
How Clients and Servers Communicate (HTTP Methods)
REST relies on standard HTTP methods to tell the server exactly what action to perform on a resource. These map directly to basic “CRUD” (Create, Read, Update, Delete) operations.
| HTTP Method | Action | Example Endpoint | What it does |
| GET | Read | GET /books | Retrieves a list of all books. |
| GET | Read | GET /books/123 | Retrieves the specific details of book ID 123. |
| POST | Create | POST /books | Adds a brand new book to the database. |
| PUT | Update | PUT /books/123 | Replaces the data of book ID 123 with new data. |
| DELETE | Delete | DELETE /books/123 | Removes book ID 123 from the database. |
The Key Rules of REST Architecture
For an API to be truly “RESTful,” it must strictly adhere to specific architectural constraints designed by computer scientist Roy Fielding in 2000.
1. Statelessness (The Golden Rule)
The server does not remember anything about the client between requests. Every single request sent from the client must contain all the necessary information (like authentication tokens or account IDs) for the server to understand and process it.
- Why it matters: It makes servers incredibly fast and scalable because they don’t have to waste memory storing “session” data for millions of users.
2. Client-Server Separation
The client (e.g., a mobile app or web browser) and the server (the database and backend logic) are completely independent. The client doesn’t need to know how the data is stored, and the server doesn’t need to know how the user interface is rendered.
3. Uniform Interface
All requests and responses must follow a consistent, standardized format. If an API returns user data in JSON format, it shouldn’t randomly return product data in XML format.
4. Cacheability
Because clients often request the same data multiple times (like a website’s logo or a list of countries), REST responses must clearly state whether they can be cached (stored temporarily) by the client. This dramatically reduces server load.
5. Layered System
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way (like a security proxy or a load balancer).
A Complete Example in Action
Imagine you are using a mobile app to check the weather in London.
1. The Request:
Your weather app (the client) makes an HTTP request to a weather API.
GET [https://api.weather.com/v1/cities/london](https://api.weather.com/v1/cities/london)
2. The Processing:
The API receives the request, checks that it’s properly formatted, and asks the database for London’s current weather conditions.
3. The Response:
The server responds with a status code (e.g., 200 OK meaning success) and sends the data back to your phone, almost always formatted in a lightweight text format called JSON (JavaScript Object Notation).
JSON
{
"city": "London",
"temperature_celsius": 14,
"condition": "Cloudy",
"humidity": "72%"
}
Your phone app takes this raw JSON data and turns it into the beautiful, user-friendly graphical interface you see on your screen.
REST (Representational State Transfer) అనేది ఒక ప్రోటోకాల్ (protocol), లాంగ్వేజ్ (language) లేదా సాఫ్ట్వేర్ (software) కాదు. ఇది వెబ్ సర్వీసెస్ (web services) బిల్డ్ చేయడానికి ఉపయోగించే ఆర్కిటెక్చరల్ రూల్స్ (architectural rules) మరియు గైడ్లైన్స్ (guidelines) సెట్. ఒక API ఈ రూల్స్ ఫాలో అయితే, దాన్ని RESTful API అంటారు.
దీన్ని ఈజీగా అర్థం చేసుకోవాలంటే ఒక రెస్టారెంట్ (restaurant) గురించి ఆలోచించండి.
- మీరు (Client) మెనూ చూసి, వెయిటర్కి ఆర్డర్ ఇస్తారు.
- వెయిటర్ (REST API) ఆ ఆర్డర్ని కిచెన్కి తీసుకెళ్తాడు.
- కిచెన్ (Server) మీ ఫుడ్ ప్రిపేర్ చేస్తుంది.
- ఆ తర్వాత వెయిటర్ ఫుడ్ (Response) తీసుకొచ్చి మీకు ఇస్తాడు.
Core Concepts of REST (REST లోని ముఖ్యమైన కాన్సెప్ట్స్)
REST API వాడాలంటే మీకు రెండు బేసిక్ కాన్సెప్ట్స్ తెలియాలి: Resources మరియు Endpoints.
- Resource: REST లో ప్రతిదీ ఒక రిసోర్స్ (resource) కిందే లెక్క. ఒక యూజర్ (user), బ్లాగ్ పోస్ట్ (blog post), ఫోటో (photo) లేదా ఆన్లైన్ స్టోర్ లోని ప్రొడక్ట్ (product) – ఇవన్నీ resources.
- Endpoint: ప్రతి రిసోర్స్ ని యాక్సెస్ (access) చేయడానికి ఒక స్పెసిఫిక్ URL ఉంటుంది. దాన్నే ఎండ్పాయింట్ (endpoint) అంటారు. ఉదాహరణకు, మీరు ఒక బుక్ స్టోర్ (bookstore) కి API క్రియేట్ చేస్తుంటే, “books” రిసోర్స్ ని యాక్సెస్ చేయడానికి వాడే URL
[https://api.bookstore.com/books](https://api.bookstore.com/books).
How Clients and Servers Communicate (క్లయింట్స్ మరియు సర్వర్స్ ఎలా కమ్యూనికేట్ చేసుకుంటాయి)
ఒక రిసోర్స్ మీద ఏం యాక్షన్ (action) చేయాలో సర్వర్కి చెప్పడానికి REST స్టాండర్డ్ HTTP మెథడ్స్ (HTTP methods) ని వాడుతుంది. ఇవి బేసిక్ “CRUD” (Create, Read, Update, Delete) ఆపరేషన్స్ (operations) తో మ్యాచ్ అవుతాయి.
| HTTP Method | Action | Example Endpoint | What it does (ఏం చేస్తుంది) |
| GET | Read | GET /books | మొత్తం బుక్స్ లిస్ట్ ని రిట్రీవ్ (retrieve) చేస్తుంది. |
| GET | Read | GET /books/123 | ID 123 ఉన్న స్పెసిఫిక్ బుక్ డీటెయిల్స్ ని ఇస్తుంది. |
| POST | Create | POST /books | డేటాబేస్ (database) లో ఒక కొత్త బుక్ ని యాడ్ (add) చేస్తుంది. |
| PUT | Update | PUT /books/123 | ID 123 ఉన్న బుక్ డేటాని కొత్త డేటాతో రీప్లేస్ (replace) చేస్తుంది. |
| DELETE | Delete | DELETE /books/123 | ID 123 ఉన్న బుక్ ని డేటాబేస్ నుండి రిమూవ్ (remove) చేస్తుంది. |
The Key Rules of REST Architecture (REST ఆర్కిటెక్చర్ లోని ముఖ్యమైన రూల్స్)
ఒక API కంప్లీట్ గా “RESTful” కావాలంటే, 2000వ సంవత్సరంలో రాయ్ ఫీల్డింగ్ (Roy Fielding) డిజైన్ చేసిన కొన్ని రూల్స్ ని స్ట్రిక్ట్ (strict) గా ఫాలో అవ్వాలి.
1. Statelessness (ఎప్పుడూ మర్చిపోవద్దు)
క్లయింట్ పంపే రిక్వెస్ట్స్ (requests) మధ్యలో సర్వర్ ఎలాంటి డేటాని గుర్తుపెట్టుకోదు. ప్రతి రిక్వెస్ట్ లో సర్వర్కి అర్థం కావడానికి కావాల్సిన మొత్తం ఇన్ఫర్మేషన్ (అథెంటికేషన్ టోకెన్స్ – authentication tokens లేదా అకౌంట్ ఐడీలు – account IDs లాంటివి) ఉండాలి.
- Why it matters: లక్షలాది మంది యూజర్స్ “సెషన్” (session) డేటాని స్టోర్ (store) చేయాల్సిన పనిలేదు కాబట్టి, ఇది సర్వర్స్ ని చాలా ఫాస్ట్ గా, స్కేలబుల్ (scalable) గా ఉంచుతుంది.
2. Client-Server Separation
క్లయింట్ (మొబైల్ యాప్ లేదా వెబ్ బ్రౌజర్) మరియు సర్వర్ (డేటాబేస్ మరియు బ్యాకెండ్ లాజిక్ – backend logic) రెండూ వేరుగా ఉంటాయి. డేటా ఎలా స్టోర్ అవుతుందో క్లయింట్కి తెలియాల్సిన అవసరం లేదు, అలాగే యూజర్ ఇంటర్ఫేస్ (user interface) ఎలా కనిపిస్తుందో సర్వర్కి తెలియాల్సిన అవసరం లేదు.
3. Uniform Interface
అన్ని రిక్వెస్ట్స్ మరియు రెస్పాన్సెస్ (responses) ఒకే స్టాండర్డ్ ఫార్మాట్ (standard format) ని ఫాలో అవ్వాలి. ఒకవేళ API యూజర్ డేటాని JSON ఫార్మాట్ లో ఇస్తే, ప్రొడక్ట్ డేటాని XML ఫార్మాట్ లో ఇవ్వకూడదు.
4. Cacheability
వెబ్సైట్ లోగో (logo) లేదా దేశాల లిస్ట్ లాంటి ఒకే డేటాని క్లయింట్స్ పదే పదే అడుగుతుంటారు కాబట్టి, ఈ డేటాని క్లయింట్ క్యాష్ (cache – టెంపరరీగా స్టోర్) చేసుకోవచ్చా లేదా అని REST రెస్పాన్సెస్ స్పష్టంగా చెప్పాలి. ఇది సర్వర్ మీద లోడ్ (load) ని చాలా తగ్గిస్తుంది.
5. Layered System
క్లయింట్ డైరెక్ట్ గా మెయిన్ సర్వర్కి కనెక్ట్ అయిందా లేదా మధ్యలో ఇంకేదైనా (సెక్యూరిటీ ప్రాక్సీ – security proxy లేదా లోడ్ బ్యాలెన్సర్ – load balancer లాంటివి) ఉందా అనేది క్లయింట్కి తెలియదు.
A Complete Example in Action (ఒక కంప్లీట్ ఉదాహరణ)
మీరు లండన్ (London) లో వెదర్ (weather) ఎలా ఉందో చెక్ చేయడానికి ఒక మొబైల్ యాప్ (mobile app) వాడుతున్నారు అనుకోండి.
1. The Request (రిక్వెస్ట్):
మీ వెదర్ యాప్ (client) వెదర్ API కి ఒక HTTP రిక్వెస్ట్ పంపుతుంది.
GET [https://api.weather.com/v1/cities/london](https://api.weather.com/v1/cities/london)
2. The Processing (ప్రాసెసింగ్):
ఆ API రిక్వెస్ట్ ని రిసీవ్ (receive) చేసుకుని, అది కరెక్ట్ ఫార్మాట్ లో ఉందో లేదో చెక్ చేసి, డేటాబేస్ ని లండన్ కరెంట్ వెదర్ కండిషన్స్ అడుగుతుంది.
3. The Response (రెస్పాన్స్):
సర్వర్ ఒక స్టేటస్ కోడ్ (status code) తో రిప్లై ఇస్తుంది (ఉదాహరణకు, సక్సెస్ అని చెప్పడానికి 200 OK) మరియు డేటాని మీ ఫోన్కి పంపుతుంది. ఇది దాదాపు ఎప్పుడూ JSON (JavaScript Object Notation) అనే లైట్వెయిట్ టెక్స్ట్ ఫార్మాట్ లో ఉంటుంది.
JSON
{
"city": "London",
"temperature_celsius": 14,
"condition": "Cloudy",
"humidity": "72%"
}
మీ ఫోన్ యాప్ ఈ రా (raw) JSON డేటాని తీసుకుని, మీరు స్క్రీన్ మీద చూసే బ్యూటిఫుల్ (beautiful) యూజర్ ఇంటర్ఫేస్ (user-friendly graphical interface) గా మారుస్తుంది.
