Rest API also known as Restful API is a Representational State Transfer Application Programming Interface or type of API which has some rules and which we should follow to conclude or infer that our server is built on Restful API.REST APIs often utilize JSON (Javascript Object Notation) as a lightweight format for data interchange, making it easy to read and write data between client and server

A python code snippet can use a REST API to fetch and process data in JSON format. So let’s discuss them-

Let say that there is a server and a client. Now this client could be anything like a browser or a mobile phone or a smart device like an Alexa. Now how these server and client are communicating-So the client is sending the Request to the server and in return the server is reverting back the Response. Now this communication method via Request and Response is based on some rules or good practices which is given by Rest API, and it is useful for Industry level and highly scalable. So, REST API works on server and client Architecture and the Rules are:

• Server is a different machine, and Client is a different machine, and both of these entities should not depend on each other i.e. basically upon the client request server will fetch the data from database and send the response in raw format to the client and client/frontend will decide how will he/she render the data.
• Always respect all HTTP methods (GET, POST, PUT, PATCH, DELETE) that is use that method only based on their working.

GET: Read the user data and return the data.

Ex-GET /users/123

This request fetches data for the user with ID 123.

POST: Handle new user creation.

Ex-POST /users
{
“name”: “Anjali”,
“email”: “thirdeye@example.com

}

 PUT: Update or create a resource on the server.

Ex-PUT /users/123
{
“name”: “Anjali”,
“email”: “gfg@example.com”
}

This request updates the user with ID 123 or creates a new user if one doesn’t exist.

PATCH: Used to partially update a resource on the server. Unlike PUT, PATCH only requires the fields that need to be updated to be sent in the request body. It modifies specific parts of the resource rather than replacing the entire resource.

Ex-PATCH /users/123
{
“email”: “new.email@example.com”
}

This request updates only the email of the user with ID 123, leaving the rest of the user data unchanged.

NOTE:

Thus, the key features of Rest API’s are:

1.Statelessness

The two party’s client and server don’t need to store information about each other and every request and response will be independent of each other. This leads to web applications that are easy to scale and well behaved. Example-When a client requests user data, it must include authentication details in each request, as the server does not remember previous requests.

2.Proper Documentation

It comes with a good documentation on how we can create Rest API using various Technologies, various frameworks and how we can embed them for various applications.

 3.Proper Error Messages

We get a proper error message upon getting stuck on creating any framework using Rest API and user can debug those error messages.

4.Client Server Architecture

It has a uniform interface facility that separates client from the server and basically helps in improving users interface portability across multiple platforms and enhance scalability of server components. Example A web browser (client) sends a request to a web server, which returns the requested web page.

5.Layered system

The layered system architecture allows the application to be more stable by limiting component behaviour and enables load balancing making it more scalable and also helps in enhancing the application security as components in each layer cannot interact beyond the next intermediate layer they are in.

6.Resources and URIs

• Description: Resources are the objects or data entities that are accessed via REST API. Each resource is identified by a Uniform Resource Identifier (URI).
• Example: /users/123 might be the URI for accessing the user with ID 123.

Statement 1: Online Food Delivery App

Goal: Let’s say you’re using a food delivery app. Behind the scenes, REST APIs are doing the work:

1. GET /restaurants
   → Shows you a list of available restaurants.
2. GET /menu/123
   → Shows the menu of restaurant with ID 123.
3. POST /order
   → Places your order.
4. PUT /order/456
   → Updates order number 456 (maybe to add a drink).
5. DELETE /order/456
   → Cancels the order.

Each of these actions is a request to a REST API, and the app receives a response — like the list of food items, confirmation messages, or updates.

Statement 2:AI Model Serving Platform (e.g., Hugging Face, OpenAI)

Goal:

Enable users to send input data and receive predictions or embeddings from hosted machine learning models.

REST API Endpoints

1. POST /predict
   → Sends input data and receives model predictions.
2. GET /models
   → Lists available models for inference.
3. GET /models/{id}/metrics
   → Retrieves performance metrics for model ID {id}.
4. POST /fine-tune
   → Submits a dataset to fine-tune a model.
5. GET /jobs/{job_id}/status
   → Checks the status of a long-running inference or training job.

Each request interacts with a REST API, and the response might include predictions, model metadata, or job progress updates.

Statement 3: ERP Attendance Tracker

Goal:

Allow employees to log attendance, view history, and enable admins to generate reports and manage users.

REST API Endpoints

1. POST /attendance
   → Logs attendance for the current user.
2. GET /attendance/{user_id}
   → Retrieves attendance history for user ID {user_id}.
3. GET /reports?range=monthly
   → Generates a monthly attendance report.
4. POST /users
   → Adds a new employee to the system.
5. DELETE /users/{id}
   → Removes employee ID {id} from the system.

Each interaction is a REST API call, and the system responds with confirmations, logs, or analytics reports.

• REST API is easy to understand and learn, due to its simplicity, known API.
• With REST API, being able to organize complicated applications & makes it easy to use resources.
• The high load can be managed with help out of HTTP proxy server & cache.
• REST API is easy to explore and discover.
• It makes it simple for new clients to work on other applications, whether it is designed specifically for purpose or not.
• Use standard HTTP procedure call- outs to retrieve data and requests.
• REST API depends on codes, can use it to synchronize data with a website without any complications.
• Users can avail access to the same standard objects and data model when compared to SOAP-based web services.
• Brings flexibility formats by serializing data in XML or JSON format.
• Allows Standard-based protection with the use of OAuth protocols to verify your REST API endpoints.

1.Over-fetching and Under-fetching

Defination:

• Overfetching:The client receives more data than actually it needs.
• Underfetching:The client receives little too less data and must make additional requests to complete the tasks.

Example:

Imagine a mobile app that displays only a restaurant’s name and rating, but the REST endpoint

This is over-fetching — unnecessary payload increases bandwidth and slows down performance.

Now suppose the app needs both restaurant info and menu, but must call:

• GET /restaurants/123
• GET /menu/123

This is under-fetching — multiple roundtrips increase latency and complexity.

Architectural Impact:

• Inefficient data transfer, especially on mobile or low-bandwidth networks.
• Increased client-side logic to stitch together fragmented data.
• Harder to optimize caching and performance.

2. Versioning Complexity

Definition:

As APIs evolve, maintaining backward compatibility often requires versioning (e.g., /v1/, /v2/). This can become messy over time.

Example:

• /v1/users returns basic user info.
• /v2/users adds profile pictures and social links.
• /v3/users restructures the response entirely.

Now, clients using different versions must handle different schemas, error formats, and logic.

Architectural Impact:

• Increased maintenance burden for developers.
• Risk of breaking older clients if versioning isn’t handled cleanly.
• Need for robust documentation and deprecation strategy.

3.Complex Queries Across Multiple Endpoints

Definition:

REST APIs often require multiple endpoints to fulfill a single complex query, especially when filtering, aggregating, or joining data.

Example:

To get all users who ordered biryani under ₹200 last week:

1. GET /orders? Dish=biryani&price_lte=200&date_range=last_week
2. Then for each order: GET /users/{user_id}

This leads to N+1 requests, increasing latency and client-side complexity.

Architectural Impact:

• Harder to optimize performance.
• Difficult to maintain clean client logic.
• May require custom aggregation endpoints or GraphQL-style flexibility.

4.Limited Flexibility in Response Structure

Definition:

REST APIs typically return fixed response formats, which may not align with what different clients need.

Example:

A dashboard wants only usernames and roles:

GET /users

Returns:

[ {“id”: 1, “name”: “Sanghamitra”, “email”: “s@example.com”, “role”: “admin”, “created at”: “…”, “last login”: “…”} ]

But the dashboard only needs name and role. The rest is wasted.

Architectural Impact:

• Clients must filter or transform data manually.
• Increases payload size and parsing overhead.
• Makes it harder to tailor responses to specific use cases.

GraphQL

GraphQL is a query language for APIs that allows clients to request only the data they need, making it more efficient than REST. Clients can specify the exact data they require and receive it in a single request, reducing the need for multiple round-trip requests. Solves over-fetching/under-fetching by letting clients request exactly the data they need. Supports nested queries and single endpoint access. This makes GraphQL ideal for data-driven applications with complex and evolving data requirements.

WebSockets

A protocol for full-duplex communication over a single TCP connection. In comparison to Rest,WebSockets Maintains persistent connections for real-time updates and Ideal for chat apps, live dashboards, or gaming and so our food-ordering chatbot could use WebSockets for live order status updates.

Serverless Functions (e.g., AWS Lambda, Azure Functions)

An Event-driven execution of backend logic without managing servers.In comparision to Rest, these functions Scales automatically and Reduces infrastructure overhead and hence can be used for Triggering order confirmation emails or payment receipts in our chatbot backend.

The Automated Product Counting System is an AI-powered solution that ensures accuracy, efficiency, and transparency in logistics and supply chain operations. Leveraging advanced computer vision models, it can automatically detect and count products—such as bags, sacks, cartons, and boxes – from images or video feeds captured during loading and unloading. This system helps enterprises verify dispatch and delivery quantities in real time, reduce manual effort, prevent losses caused by discrepancies, and provide a verifiable audit trail across the supply chain. With seamless ERP/WMS integration, scalable deployment, and adaptability to diverse environments, it enables organizations to achieve greater operational reliability and control.

Here’s a super simple Hello World REST API in pure Python using the built-in http.server module:

from http.server import BaseHTTPRequestHandler, HTTPServer

class HelloHandler(BaseHTTPRequestHandler):

def do_GET(self):

if self.path == “/hello”:

self.send_response(200)

self.send_header(“Content-type”, “application/json”)

self.end_headers()

self.wfile.write(b'{“message”: “Hello, World!”}’)

else:

self.send_response(404)

self.end_headers()

# Run the server

server = HTTPServer((‘localhost’, 8000), HelloHandler)

print(“Server running on http://localhost:8000/hello”)

server.serve_forever()

Run this file and visit http://localhost:8000/hello in our browser or use curl — we’ll get a JSON response:

{“message”: “Hello, World!”}

What are the common HTTP status codes in Rest API?

• 200 OK: Successful request

• 201 Created: Successful resource creation

• 400 Bad Request: Invalid syntax

• 401 Unauthorized: Authentication required

• 403 Forbidden: Server understood but refuses to authorize

• 404 Not Found: Resource not found

• 500 Internal Server Error: Generic server error

What are the Rest API Design principles?

Designing a REST API that is both effective and easy to use requires adherence to certain principles. Here are some key design principles to consider:

1. Use Nouns, Not Verbs in Endpoint Paths

Good: /articles Bad: /get Articles

2. Use Logical Nesting on Endpoints

For relationships: /articles/1/comments

3.Allow Filtering, Sorting, and Pagination

Implement these features to make your API more flexible: /articles? Sort=date&order=asc&page=2

4.Versioning

Include the version in the URL or as a header: /v1/article

What do you mean by Resource in Rest API?

A resource is any piece of information that can be named, such as:

• A document

• An image

• A temporal service

• A collection of other resources

Resources are identified by URIs (Uniform Resource Identifiers). When a client requests a resource, they receive a representation of that resource, typically in JSON or XML format.

 What is content type and paths in Rest API?

Content Type:

In cases where the server is sending a data payload to the client, the server must include a content-type in the header of the response. This content-type header field alerts the client to the type of data it is sending in the response body. These content types are MIME Types, just as they are in the accept field of the request header. The content-type that the server sends back in the response should be one of the options that the client specified in the accept field of the request.

For example, when a client is accessing a resource with id 23 in an articles resource with this GET Request:

GET /articles/23 HTTP/1.1

Accept: text/html, application/xHTML

The server might send back the content with the response header:

HTTP/1.1 200 (OK)

Content-Type: text/html

This would signify that the content requested is being returned in the response body with a content-type of text/html, which the client said it would be able to accept.

Paths:

Requests must contain a path to a resource that the operation should be performed on. In RESTful APIs, paths should be designed to help the client know what is going on.

Conventionally, the first part of the path should be the plural form of the resource. This keeps nested paths simple to read and easy to understand.

A path like fashionboutique.com/customers/223/orders/12 is clear in what it points to, even if you’ve never seen this specific path before, because it is hierarchical and descriptive. We can see that we are accessing the order with an id of 12 for the customer with an id of 223.

Paths should contain the information necessary to locate a resource with the degree of specificity needed. When referring to a list or collection of resources, it is not always necessary to add an id. For example, a POST request to the fashionboutique.com/customers path would not need an extra identifier, as the server will generate an id for the new object.

If we are trying to access a single resource, we would need to append an id to the path.

For example:

• GET fashionboutique.com/customers/:id: Retrieves the item in the customers resource with the id specified.
• DELETE fashionboutique.com/customers/:id: Deletes the item in the customers resource with the id specified.

In simple words, in the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs).The resources are acted upon by using a set of simple, well-defined operations. Also, the resources have to be decoupled from their representation so that clients can access the content in various formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others.The clients and servers exchange representations of resources by using a standardized interface and protocol. Typically, HTTP is the most used protocol, but REST does not mandate it.Metadata about the resource is made available and used to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control.And most importantly, every interaction with the server must be stateless. All these principles help RESTful applications to be simple, lightweight, and fast.