1. REST API Basics and Core Concept
Define REST and API in simple terms
Explain how REST APIs enable applications to communicate
Briefly introduce the client-server model
2. How REST APIs Work
Explain the request-and-response process
Describe clients, servers, endpoints, and resources
Explain HTTP methods such as GET, POST, PUT, PATCH, and DELETE
3. Key Principles of REST Architecture
Stateless communication
Client-server separation
Uniform interface
Resource-based architecture
Cacheable responses and layered systems
4. HTTP Methods, Status Codes, and Data Formats
When to use each HTTP method
Common HTTP status codes
JSON and other data formats
Headers, parameters, and request bodies
5. REST API Example: From Request to Response
Walk through a practical API request
Show a sample endpoint
Demonstrate a request and JSON response
Explain each part of the example
6. REST API Authentication and Security
API keys, tokens, and OAuth
HTTPS and secure data transmission
Authorization and access control
Common REST API security practices
7. Advantages, Limitations, and Common Use Cases
Benefits of using REST APIs
Potential limitations and challenges
Real-world applications such as mobile apps, websites, and third-party integrations
REST compared with traditional API approaches
8. How to Build and Use a REST API
Basic steps for designing an API
Choosing a backend technology
Creating endpoints and handling requests
Testing and documenting an API
Best practices for scalable and maintainable REST APIs
2. How REST APIs Work
A REST API works as a communication layer between a client and a server. The client sends a request, and the server processes it and returns a response.
For example, when you open a mobile shopping app and view your orders, the app may send a REST API request to the server. The server finds your order data and sends it back to the app.
Client and Server
REST follows a client-server architecture. The two sides have different responsibilities.
Client: The application that sends the request. It can be a website, mobile app, desktop application, or another service.
Server: The system that receives the request, processes it, accesses the required data, and sends a response.
This separation makes applications easier to develop and maintain. The client focuses on the user interface, while the server handles business logic and data.
REST API Requests
A REST API request usually contains several important parts:
URL: Identifies the API resource.
HTTP method: Defines what action the client wants to perform.
Headers: Provide additional information about the request.
Parameters: Provide specific information needed by the server.
Request body: Contains data sent to the server when required.
For example:
GET https://example.com/api/users/25
Here, GET tells the server that the client wants to retrieve information. The URL identifies the user resource with the ID 25.
API Endpoints
An endpoint is a specific URL through which a client can access a resource or perform an operation.
For example:
GET /api/users
GET /api/users/25
POST /api/users
PUT /api/users/25
DELETE /api/users/25
Each endpoint can perform a different operation.
A REST API may use resources such as:
Users
Products
Orders
Posts
Payments
Categories
For example, /api/products could represent a collection of products, while /api/products/10 could represent one specific product.
HTTP Methods
REST APIs commonly use standard HTTP methods to tell the server what action to perform.
GET is used to retrieve data.
GET /api/products
This could return a list of products.
POST is generally used to create new data.
POST /api/products
The request body might contain the new product’s name, price, and description.
PUT is commonly used to replace or update an existing resource.
PUT /api/products/10
PATCH is commonly used to update specific parts of a resource.
PATCH /api/products/10
DELETE removes a resource.
DELETE /api/products/10
These methods give REST APIs a consistent way to work with resources.
REST API Responses
After receiving a request, the server processes it and sends a response back to the client.
A response usually includes:
An HTTP status code
Response headers
Data, often in JSON format
For example:
{
“id”: 25,
“name”: “John”,
“email”: “john@example.com”
}
The client can then use this data to display information to the user.
Example of a Complete Request and Response
Imagine a mobile application needs information about a customer.
The application sends:
GET /api/customers/25
The server receives the request and searches for customer 25.
If the customer exists, the server could respond with:
200 OK
Along with:
{
“id”: 25,
“name”: “John”,
“email”: “john@example.com”
}
The application receives the response and displays the customer’s information.
If the customer does not exist, the server could return:
404 Not Found
This tells the client that the requested resource could not be found.
Stateless Communication
One important REST principle is statelessness. Each request should contain the information the server needs to process it.
The server does not normally rely on previous requests to understand the current request.
For example, if a user sends a request to access protected data, the request can include an authentication token. The server uses that token to determine whether the request is authorized.
Stateless communication makes REST APIs easier to scale because requests can be handled independently by different servers.
The REST API Flow
The basic process can be summarized as:
Client → HTTP Request → REST API → Server → HTTP Response → Client
For example:
Mobile App
↓
GET /api/products
↓
REST API
↓
Database
↓
JSON Response
↓
Mobile App
The API acts as the bridge between the application and the server-side resources.
Understanding this request-and-response process is essential before learning about REST principles, authentication, status codes, and API design.
4. HTTP Methods, Status Codes, and Data Formats
REST APIs rely heavily on HTTP. HTTP provides the methods, status codes, headers, and communication rules that allow clients and servers to exchange data.
Understanding these elements makes it easier to work with REST APIs and troubleshoot problems.
HTTP Methods in REST APIs
HTTP methods tell the server what the client wants to do with a resource.
GET
The GET method retrieves data from the server.
For example:
GET /api/products
This request could return a list of products.
You can also request a specific resource:
GET /api/products/10
This could return the product with ID 10.
GET requests should generally be used for retrieving information rather than changing data.
POST
The POST method is commonly used to create a new resource.
For example:
POST /api/products
The request may include product information in its body:
{
“name”: “Wireless Headphones”,
“price”: 49.99
}
The server processes the data and creates a new product.
PUT
The PUT method is commonly used to replace or completely update an existing resource.
For example:
PUT /api/products/10
The request body could contain the updated resource:
{
“name”: “Wireless Headphones Pro”,
“price”: 59.99
}
PUT is generally used when the client intends to provide the complete updated representation.
PATCH
The PATCH method is used when only part of a resource needs to be changed.
For example:
PATCH /api/products/10
The client might send only the field that needs updating:
{
“price”: 54.99
}
This can be useful when updating a small part of an existing resource.
DELETE
The DELETE method removes a resource.
For example:
DELETE /api/products/10
The server can use the product ID to identify and remove the resource.
HTTP Status Codes
After processing a request, the server returns an HTTP status code. This code tells the client whether the operation was successful or whether something went wrong.
Status codes are grouped into five categories:
1xx: Informational responses
2xx: Successful requests
3xx: Redirection
4xx: Client errors
5xx: Server errors
Some commonly used REST API status codes include:
200 OK
The request was successful.
For example, a successful GET request may return:
200 OK
along with the requested data.
201 Created
The request successfully created a new resource.
A successful POST request may return:
201 Created
204 No Content
The request was successful, but there is no response body to return.
This is often used after successfully deleting a resource.
400 Bad Request
The server could not process the request because the client sent invalid or incomplete data.
For example, an API may return 400 Bad Request when required fields are missing.
401 Unauthorized
The request requires authentication, but the client has not provided valid authentication credentials.
For example, an expired or missing authentication token may result in a 401 response.
403 Forbidden
The server understood the request but refuses to allow access.
This can happen when an authenticated user does not have permission to access a particular resource.
404 Not Found
The requested resource could not be found.
For example:
GET /api/products/9999
could return 404 Not Found if product 9999 does not exist.
429 Too Many Requests
The client has sent too many requests within a specific period.
APIs often use this response when enforcing rate limits.
500 Internal Server Error
Something went wrong on the server while processing the request.
This usually indicates a server-side problem rather than an issue with the client’s request.
Data Formats Used by REST APIs
REST APIs need a structured way to exchange information between clients and servers.
JSON (JavaScript Object Notation) is the most common format used by modern REST APIs.
A JSON response might look like this:
{
“id”: 10,
“name”: “Laptop”,
“price”: 899.99,
“available”: true
}
JSON is popular because it is lightweight, human-readable, and supported by almost every modern programming language.
Other formats can also be used, including XML, CSV, and plain text. However, JSON is generally preferred for most modern web and mobile APIs.
HTTP Headers
HTTP headers provide additional information about a request or response.
For example, a client can specify that it expects JSON:
Accept: application/json
When sending JSON data, the client can specify its content type:
Content-Type: application/json
Authentication information can also be sent through headers. For example:
Authorization: Bearer YOUR_TOKEN
Headers help the client and server understand how the request or response should be handled.
Query Parameters and Path Parameters
REST APIs often need additional information to identify or filter resources.
A path parameter is part of the URL path:
GET /api/products/10
Here, 10 identifies a specific product.
A query parameter is added after a ? in the URL:
GET /api/products?category=phones&limit=10
Query parameters are useful for filtering, searching, sorting, and pagination.
For example:
/api/products?category=phones
could return only phones, while:
/api/products?page=2&limit=20
could request the second page with 20 products.
Request Body
A request body contains data sent from the client to the server. It is commonly used with POST, PUT, and PATCH requests.
For example:
POST /api/users
Content-Type: application/json
The body could contain:
{
“name”: “John”,
“email”: “john@example.com”
}
The server reads this information and uses it to create or process the requested resource.
Putting Everything Together
A typical REST API request can combine several of these elements:
POST /api/users
Content-Type: application/json
Authorization: Bearer YOUR_TOKEN
Request body:
{
“name”: “John”,
“email”: “john@example.com”
}
The server may then return:
201 Created
Content-Type: application/json
with a response such as:
{
“id”: 25,
“name”: “John”,
“email”: “john@example.com”
}
This simple structure is one reason REST APIs are widely used. Clients and servers can communicate using standardized HTTP methods, clear status codes, headers, and structured data formats.
5. REST API Example: From Request to Response
The best way to understand a REST API is to see how a real request works. Let’s use a simple online store as an example.
Imagine a mobile shopping app that needs to display a list of products. The app does not usually store all product information itself. Instead, it requests the data from a server through a REST API.
Step 1: The Client Sends a Request
The mobile app sends an HTTP request to the API.
For example:
GET https://example.com/api/products
Here:
GET is the HTTP method.
https://example.com is the API server.
/api/products is the endpoint.
products represents the resource the client wants to access.
The request tells the server that the client wants to retrieve product information.
Step 2: The Server Receives the Request
The server receives the request and identifies the requested endpoint.
It may then:
Check whether the request is valid.
Verify authentication if required.
Apply business rules.
Query the database.
Prepare the requested data.
Send a response back to the client.
For example, the server may run a database query to find available products.
Step 3: The Server Queries the Database
The REST API itself may not permanently store the product information. Instead, the backend can communicate with a database such as PostgreSQL, MySQL, or MongoDB.
The server might retrieve information such as:
Product ID: 101
Name: Wireless Headphones
Price: $49.99
Stock: 25
The backend then converts the required information into a format the client can understand.
Step 4: The Server Sends a Response
If everything works correctly, the server returns an HTTP response.
For example:
HTTP/1.1 200 OK
Content-Type: application/json
The response body could contain:
{
“products”: [
{
“id”: 101,
“name”: “Wireless Headphones”,
“price”: 49.99,
“stock”: 25
},
{
“id”: 102,
“name”: “Bluetooth Speaker”,
“price”: 39.99,
“stock”: 18
}
]
}
The 200 OK status tells the client that the request was successful.
Step 5: The Client Processes the Response
The mobile app receives the JSON response. It then converts the data into objects or another structure that its code can use.
The application can display the products on the screen:
Wireless Headphones
$49.99
Bluetooth Speaker
$39.99
The user sees the final result without needing to know how the API or database works behind the scenes.
A REST API Example With a Specific Product
Now suppose the user taps on the Wireless Headphones.
The app needs more information about that product. It can send another request:
GET /api/products/101
The number 101 identifies the specific product.
The server may return:
{
“id”: 101,
“name”: “Wireless Headphones”,
“price”: 49.99,
“description”: “Wireless headphones with Bluetooth connectivity.”,
“stock”: 25
}
The app can then use this information to display the product details page.
Creating Data With POST
REST APIs are not only used to retrieve information. They can also create new resources.
For example, suppose a user creates an account. The application could send:
POST /api/users
Content-Type: application/json
Request body:
{
“name”: “John”,
“email”: “john@example.com”,
“password”: “secure-password”
}
The server validates the information and creates the user in the database.
If successful, it might return:
201 Created
with a response such as:
{
“id”: 25,
“name”: “John”,
“email”: “john@example.com”
}
A real application should never return a user’s password in the response.
Updating Data With PATCH
Suppose the user changes their name.
The application could send:
PATCH /api/users/25
Content-Type: application/json
Request body:
{
“name”: “John Smith”
}
The server updates the user’s name and may return:
200 OK
along with the updated information.
PATCH is useful when only specific fields need to change.
Deleting Data With DELETE
Suppose a user removes a product from their saved list.
The application could send:
DELETE /api/wishlist/101
If the operation succeeds, the server might return:
204 No Content
The client can then remove the item from the user interface.
What Happens When Something Goes Wrong?
Not every request is successful.
For example, if the client requests a product that does not exist:
GET /api/products/9999
The server could respond with:
404 Not Found
It may also return useful information in JSON:
{
“error”: “Product not found”
}
Similarly, an invalid request might produce:
400 Bad Request
An unauthenticated request might return:
401 Unauthorized
These status codes help the client understand what happened and decide how to respond.
The Complete REST API Flow
A typical REST API interaction can be summarized like this:
User
↓
Mobile App / Website
↓
HTTP Request
↓
REST API Endpoint
↓
Backend Logic
↓
Database
↓
Backend Logic
↓
HTTP Response
↓
Mobile App / Website
↓
Information Displayed to User
The important point is that the client does not need to know how the server stores or processes the data. It only needs to understand the API’s rules, endpoints, request format, and response format.
This separation allows the same REST API to serve different clients. For example, a single backend can provide data to a Flutter mobile app, a web application, and another service.
Once you understand this request-to-response cycle, concepts such as authentication, error handling, API design, and security become much easier to understand.
Introduction
Modern apps need a way to communicate with servers and share data. This is where APIs come in. A REST API is one of the most popular ways to make this communication possible.
REST APIs allow websites, mobile apps, and other services to request, send, update, and delete data through standard HTTP methods. They are simple, flexible, and widely supported.
But how does a REST API actually work? What are endpoints, HTTP methods, status codes, and authentication? And how can you build and use one?
In this guide, you’ll learn the fundamentals of REST APIs, how they work, their key principles, practical examples, security considerations, and best practices.
Conclusion
REST APIs provide a simple and flexible way for applications to communicate with servers. They use standard HTTP methods, endpoints, status codes, headers, and data formats such as JSON to exchange information. From retrieving products to creating users and updating data, REST APIs power many modern websites and mobile apps. Understanding how requests and responses work gives you a strong foundation for building and using APIs effectively. With the right security and design practices, REST APIs can become a reliable part of scalable applications.
