Statelessness in REST APIs – Java Backend Interview
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Statelessness in REST means every request carries the context needed to understand it. The server must not need a private memory of what this client did in an earlier request. For example, GET /orders/42 identifies the order and sends the headers and credential needed for that read.
A multi-step checkout can still work. POST /checkouts creates checkout CH-21 in shared storage and returns /checkouts/CH-21. The next request names that resource and sends its credential again. It may reach a different server instance, which can load the same checkout and continue without access to the first process's memory.
This does not mean “the server stores nothing.” Orders, users, inventory, permission records, and checkouts may remain in databases or shared stores. Those are resource or application state. The forbidden dependency is hidden conversation state, such as one server remembering the current checkout step when the next request does not identify any saved checkout. A credential may be a JWT or an opaque token; REST does not choose the token format.
Removing the hidden session dependency makes a request easier to inspect, route, and recover after a process failure. It also helps horizontal scaling when instances share the required data and configuration. The trade-off is repeated context, credentials, and lookups. Statelessness does not make every response cacheable or every retry safe; cache rules, HTTP method semantics, and business idempotency are separate decisions.
Statelessness in REST APIs – Java Backend Interview
Direct Answer
Statelessness in REST means every request can be understood without the server remembering a private conversation from earlier requests. The server may still store users, orders, permissions, and other resource data; it simply must not depend on hidden per-client session context to understand the next request.
Deep Dive & Architecture
What “stateless” applies to
The word describes the request-to-request conversation, not the whole application. The server can store products, orders, users, permissions, and payment records. Each new request must identify what it needs and carry the context required to process it.
Compare two designs for a checkout. In the first design, server A stores only an in-memory note saying, “this shopper is paying for cart C-9.” A later request sends only POST /pay. If it reaches server B, B cannot know which cart or checkout the request means. The request depends on a hidden conversation.
In the stateless design, POST /checkouts creates checkout CH-21 as stored business data. A later request sends POST /checkouts/CH-21/payment with the payment details and authorization again. The resource keeps the business progress; the request does not depend on one process remembering the previous step.
Authentication is still possible
The request can send Authorization: Bearer .... The token may contain claims, or it may be an opaque value that the server looks up. Both can support a stateless interaction because the request presents the credential needed to identify and authorize the caller. REST does not require JWT and does not prevent a permissions lookup.
What the constraint gives—and what it does not
A self-contained request is easier to understand from one log entry. A load balancer is not forced to return the same user to the same process, and another instance can continue after a failure when it can reach the same resources. This removes one scaling problem; it does not remove database bottlenecks, shared configuration, or network failures.
The main cost is repetition. Credentials, locale, tracing information, and other context may travel on every request, and the server may repeat lookups. A stateless POST can still be unsafe to retry, and a stateless response is not automatically cacheable. Those are separate HTTP and business rules.
Code Example
POST /checkouts HTTP/1.1
Host: api.example.com
Authorization: Bearer opaque-access-token
Content-Type: application/json
{"cartId":"C-9"}
HTTP/1.1 201 Created
Location: /checkouts/CH-21
GET /checkouts/CH-21 HTTP/1.1
Host: api.example.com
Authorization: Bearer opaque-access-token
The later request names the saved checkout and presents its credential. It does not need to reach the process that handled the first request.
Check your understanding
Answer these without looking back at the article.
- Why does statelessness not mean no database?
- Does a stateless API require JWT?
- How can a multi-step workflow remain stateless at the request layer?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.