REST API — How Do Applications Communicate Over HTTP?

REST (Representational State Transfer) is an architectural style used to design APIs that allow applications to communicate over HTTP.

A REST API exposes resources through URLs and uses standard HTTP methods to perform operations on those resources.

1. Why Do We Need REST APIs?

Modern applications usually have multiple components such as a React frontend, backend services, and databases.

flowchart LR
React["React Frontend"]
API["ASP.NET Core REST API"]
DB["SQL Server"]

React --> API
API --> DB

The frontend does not directly access the database. It communicates with the backend through APIs.

2. REST API Example

Suppose we have an application managing customers.

GET /api/customers

The API returns customer resources.

{
  "id": 101,
  "name": "John"
}

3. REST Resources

REST APIs are generally designed around resources.

/customers
/orders
/products
/payments

The URL identifies the resource, while the HTTP method describes the operation.

4. HTTP Methods

Method	Purpose	Example
GET	Read resource	GET /customers/101
POST	Create resource	POST /customers
PUT	Replace/update resource	PUT /customers/101
PATCH	Partially update resource	PATCH /customers/101
DELETE	Delete resource	DELETE /customers/101

5. REST Request Flow

sequenceDiagram
Client->>API: GET /api/customers/101
API->>Database: Query customer
Database-->>API: Customer data
API-->>Client: HTTP 200 + JSON

6. HTTP Status Codes

REST APIs use HTTP status codes to communicate the result of an operation.

Status	Meaning
200	OK
201	Created
204	No Content
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
409	Conflict
500	Internal Server Error

7. Statelessness

One of the important REST principles is statelessness.

Each request should contain the information required by the server to process that request. The server should not depend on previous requests stored in server-side session state.

sequenceDiagram
Client->>API: Request + Authentication
API-->>Client: Response

Client->>API: Another Request + Authentication
API-->>Client: Response

Stateless APIs are easier to scale horizontally because any healthy server instance can process a request.

8. REST API and Horizontal Scaling

flowchart LR
Client --> LB["Load Balancer"]
LB --> API1["API Server 1"]
LB --> API2["API Server 2"]
LB --> API3["API Server 3"]

Because requests are stateless, traffic can be distributed across multiple API instances.

9. JSON Response

REST APIs commonly exchange data using JSON.

{
  "id": 101,
  "name": "John",
  "email": "john@example.com"
}

10. REST API in ASP.NET Core

ASP.NET Core provides built-in support for creating REST APIs using controllers or minimal APIs.

[HttpGet("{id}")]
public async Task<ActionResult<Customer>> GetCustomer(int id)
{
    var customer = await service.GetCustomerAsync(id);

    if (customer == null)
        return NotFound();

    return Ok(customer);
}

A request such as:

GET /api/customers/101

can be handled by this endpoint.

11. REST API Authentication

REST APIs commonly use authentication mechanisms such as OAuth 2.0, OpenID Connect, or JWT-based authentication.

sequenceDiagram
Client->>API: Request + Access Token
API->>Authentication: Validate Token
Authentication-->>API: Valid
API-->>Client: Response

12. Good REST URL Design

Prefer resource-oriented URLs:

GET    /api/customers
GET    /api/customers/101
POST   /api/customers
PUT    /api/customers/101
DELETE /api/customers/101

Avoid putting the HTTP action directly into the URL when the HTTP method already expresses the operation.

GET /api/getCustomers
POST /api/createCustomer

13. Pagination

APIs should generally avoid returning thousands or millions of records in a single response.

GET /api/customers?page=1&pageSize=20

Pagination reduces response size and database/application load.

14. REST API Versioning

APIs may evolve over time. Versioning can help introduce breaking changes while maintaining compatibility with existing clients.

/api/v1/customers
/api/v2/customers

15. REST API in a Microservices Architecture

flowchart LR
Client --> Gateway["API Gateway"]
Gateway --> Order["Order Service"]
Gateway --> Payment["Payment Service"]
Gateway --> Customer["Customer Service"]

Each service can expose its own REST endpoints while the API Gateway provides a common entry point for clients.

16. REST vs Direct Database Access

A frontend should generally communicate with the backend API rather than directly connecting to the database.

flowchart LR
Client --> API
API --> Database

This allows the backend to enforce authentication, authorization, validation, business rules, auditing, and other application concerns.

17. Important Interview Questions

• What is REST?
• What is a REST API?
• What are REST resources?
• What is the difference between GET, POST, PUT, PATCH, and DELETE?
• What does stateless mean in REST?
• Why are REST APIs easy to scale horizontally?
• What HTTP status codes do you commonly use?
• What is idempotency?
• How do you design RESTful URLs?
• How do you handle pagination?
• How do you version a REST API?
• How do you secure a REST API?
• REST API vs gRPC — when would you use each?

Key Takeaways

• REST is an architectural style for designing network APIs.
• REST commonly uses HTTP methods and resource-oriented URLs.
• GET reads, POST creates, PUT replaces, PATCH partially updates, and DELETE removes resources.
• Statelessness allows requests to be distributed across multiple servers.
• JSON is commonly used for REST request and response data.
• HTTP status codes communicate the result of an operation.
• Pagination is important for large datasets.
• Authentication and authorization should be enforced by the API.

Conclusion

REST provides a simple and widely adopted way for clients and backend services to communicate using HTTP.

In system design interviews, focus especially on statelessness, HTTP methods, status codes, idempotency, pagination, versioning, authentication, and scalability.