REST API, State/Stateless, and Idempotency

What is a REST API?

REST (Representational State Transfer) is an architectural style for designing networked applications. It uses HTTP methods to perform operations on resources represented in JSON, XML, or other formats.

Core Principles of REST:

• Client-Server: Separate user interface from data storage concerns.
• Stateless: Each request from client to server must contain all the information needed to understand and process the request.
• Cacheable: Responses should define themselves as cacheable or not.
• Uniform Interface: Consistent way to interact with resources.

State vs Stateless

Stateful System

• Server remembers previous interactions.
• Example: Server tracks session data between requests.
• Problem: Scalability is harder because the server must maintain session information.

Stateless System (REST requirement)

• Each HTTP request is independent.
• Server does not store client context between requests.
• Every request must include all the information the server needs to process it (e.g., authentication tokens).

In REST API:

• Statelessness ensures better scalability, reliability, and simplicity.

Idempotency in REST

What is Idempotency?

• An operation is idempotent if performing it multiple times has the same effect as performing it once.

Examples:

• GET: Retrieve data → Safe to call multiple times.
• PUT: Update a resource → Repeating the same update doesn’t change the result.
• DELETE: Deleting an already deleted resource doesn’t cause further changes.

Non-Idempotent Example:

• POST: Creating a resource (like creating a new user) → Each call can create a new entry.

Idempotency is crucial in distributed systems where network issues can cause retries. It prevents unintended side effects.

Summary

• REST API: Uses HTTP to manage resources in a stateless, standardized way.
• Stateful vs Stateless: Stateless APIs are easier to scale and maintain.
• Idempotency: Ensures repeated API calls won’t accidentally change the system.

Would you also like a simple diagram showing a stateless request/response flow?

Interview angle

• “Which HTTP methods are idempotent?” - GET, PUT, DELETE and HEAD by definition; POST is not. Idempotent means repeating the request leaves the same server state, not that the response is identical.
• “How do you make POST safely retryable?” - a client-supplied idempotency key stored with the result. On a repeat, return the original response rather than performing the action again. The key must be stable across retries and the record written in the same transaction as the effect.
• “Why does this matter more than it looks?” - a timeout is precisely the case where the client doesn’t know whether the operation applied. Without idempotency, the safe choice is to not retry, which means giving up on a request that probably succeeded.