REST API Interview Questions

In REST conventions, POST is the method used to create a new resource: the client sends the representation to a collection URI and the server assigns the identifier of the new resource. GET retrieves representations, DELETE removes a resource, and HEAD returns only the headers that GET would return, with no body. None of those three is the conventional choice for creating a resource.

Statelessness is the REST constraint that requires each request to carry all the information needed to process it, so the server does not rely on session state stored from earlier requests. Other constraints in Fielding's set address different concerns, such as the separation of client and server responsibilities, layering of intermediaries, caching, and optional code delivery, and none of them governs whether the server holds session state. The correct answer is therefore statelessness.

HATEOAS is an acronym for Hypermedia As The Engine Of Application State, a constraint of REST. It requires responses to embed hypermedia links that describe the actions and resources reachable from the current state, which lets the client discover next steps at runtime instead of hard-coding endpoint URLs.

REST stands for Representational State Transfer, an architectural style for distributed hypermedia systems introduced by Roy Fielding in his 2000 doctoral dissertation. It defines a set of constraints (client-server, statelessness, cacheability, uniform interface, layered system, and code-on-demand) that APIs may follow to be considered RESTful.

False. REST is stateless by design: one of its architectural constraints is that the server must not store client-specific session state between requests. Each request must be self-contained and carry all the context the server needs, such as in headers, query parameters, or the body. Because no server holds session data, any server instance can handle any request, which supports scalability.

Statelessness is one of the architectural constraints Roy Fielding defined for REST. The server handles each request independently, without relying on session or application state stored from earlier requests, so each request must be self-describing. This improves scalability and reliability because any server instance can handle any request.

Idempotency is a key property in REST. GET, PUT, and DELETE are idempotent HTTP methods: repeated identical calls have the same effect as a single call. POST is intentionally not idempotent because it is used to create new resources or trigger non-repeatable actions, so each call can produce a distinct result.

Fielding's dissertation defines REST through a set of architectural constraints: client–server separation, statelessness, cacheability, a uniform interface, a layered system, and the optional code on demand. Client–server separation, statelessness, and cacheable responses are all on that list, so they are not the answer. Distributed transactions are a data-consistency and coordination mechanism (for example two-phase commit) that is not part of the REST architectural style, which makes it the option that does not belong.

Fielding's statelessness constraint requires that every client request be self-contained, carrying all the information the server needs to understand and process it, so the server retains no conversational context between requests. The distractors describe server-side sessions or identifier-based lookups, which are exactly the stored state statelessness forbids, and a persistent connection that the server uses to track a conversation, which is also server-held context. This self-contained design lets any server instance handle any request, improving scalability and reliability.

The Richardson Maturity Model, introduced by Leonard Richardson, describes four levels of REST maturity. Level 0 is plain RPC over HTTP: a single endpoint (often POST) carries method names and arguments in the body, and the protocol is used merely as a transport. Level 1 introduces resource orientation: each noun gets its own distinct URI, but the API still typically uses a single verb such as POST for all actions. Level 2 adds correct use of HTTP verbs (GET, PUT, POST, DELETE, PATCH) and standard HTTP status codes, so the protocol's semantics are respected. Level 3 adds HATEOAS, where responses include hypermedia links that guide the client to the next valid actions, decoupling the client from hardcoded URIs. Each level builds on the previous one, so the correct order from least to most RESTful is plain RPC, distinct resource URIs, correct verbs and status codes, then HATEOAS.

GET is the method that is both safe and idempotent under RFC 7231. It is defined as a read-only retrieval that must not modify server state, so it is safe. Repeating the same GET returns the same representation without further change, so it is idempotent. The other methods each fail at least one property: POST is neither safe nor idempotent because it typically creates new resources on each call, while PUT and DELETE are idempotent (repeating them leaves the same final state) but not safe, because they modify server state.

The model builds up in layers. Level 0 tunnels every operation through one URI and typically one verb, as in RPC. Level 1 splits the API into multiple resource URIs, one per entity. Level 2 adds the correct HTTP verbs and status codes so that the uniform interface is used properly. Level 3 adds hypermedia controls (HATEOAS), so responses tell the client which actions are available next. Each level builds on the one below it, so the order is strictly from Level 0 to Level 3.

The back directly describes HATEOAS — responses carry hypermedia links that tell the client what actions are available next, so the client need not hard-code URI patterns — and then gives a concrete example: a GET /orders/123 response whose _links object exposes payment and cancel relation links the client follows dynamically. This matches the prompt's two explicit requirements: a brief description and a concrete example.

Statelessness means no client session context is stored on the server between requests — each request is self-contained (e.g. carries its own auth token), which is what lets any server instance handle any request and makes horizontal scaling and load balancing straightforward. It says nothing about persistent application data, which servers absolutely do store.

REST (Fielding) is defined by constraints including client-server separation, statelessness, cacheability, a uniform interface, layered system, and optional code-on-demand. Statelessness and the uniform interface are the two most distinctive: together they decouple clients from servers and let any server instance serve any request.

Each layer builds on the one before: name resolution, then a transport connection, then TLS over that connection, and only then the HTTP exchange. REST's stateless, layered design means the server processes each self-contained request independently and any number of intermediaries (proxies, load balancers, caches) can sit transparently between client and origin.

REST's stateless constraint (Fielding's second constraint) requires each client request to contain all the information the server needs to understand and process it, and forbids the server from storing per-client context between requests. A server that keeps a map of session IDs to user data must consult that stored state to interpret a request, so the request is not self-descriptive and the design breaks statelessness. The other constraints do not fit this scenario: the uniform interface concerns resource identification and manipulation through representations, cacheable responses concern labeling responses as cacheable, and the layered system constraint concerns intermediaries between client and server; server-side sessions do not violate any of these.

HATEOAS stands for Hypermedia As The Engine Of Application State. It requires that resource representations include hypermedia controls (links, forms, or action descriptors) so the client can discover the valid next transitions at runtime. This decouples the client from the server's URI structure and is a core part of the Uniform Interface constraint.

In Fielding's REST architectural style, the statelessness constraint requires that each client request contains all information needed to process it, without the server relying on stored session (application) state from previous interactions. This does not forbid the server from holding resource state such as user credentials in a database, nor does it forbid the client from sending authentication tokens or credentials with each request. A strong answer distinguishes session state from resource state and notes that authentication can be performed independently per request, so requiring authentication does not violate statelessness.

The defining rule of PUT is full replacement of the target resource state by the request representation (RFC 9110 §9.3.4, which supersedes RFC 7231 §4.3.4). A handler that updates only the fields present in the body is performing a partial modification, which is the job of PATCH (RFC 5789). The correct fix is either to make PUT a full replacement, where omitted fields take default or empty values, or to serve partial changes through PATCH. Other aspects of the design, such as returning 200 OK for a GET of an existing resource or using UUIDs as identifiers, are not violations and are not the issue here.

Fielding's statelessness constraint requires that each client-to-server request contain all information necessary to understand the request, without the server relying on stored session state from prior interactions. The client must manage any application state. This design improves scalability because servers need not maintain per-client state across requests, and improves reliability because each request can be processed and retried independently. The main trade-off is increased network overhead, since repetitive context data must be included in every request.

The Richardson Maturity Model (proposed by Leonard Richardson) maps the incremental steps toward REST: Level 1 introduces resources (individually addressable URIs), Level 2 adds the correct use of HTTP verbs and status codes, and Level 3 adds hypermedia controls (HATEOAS) so clients can discover next actions from links in responses rather than hard-coding URIs. A correct answer must name all three concepts: resources, HTTP verbs, and hypermedia controls/HATEOAS, each tied to its level and to what it adds.

In Fielding's dissertation, the uniform interface constraint has exactly four sub-constraints: identification of resources, manipulation of resources through representations, self-descriptive messages, and hypermedia as the engine of application state (HATEOAS). The layered system is a separate top-level constraint, listed alongside client-server, statelessness, cacheability, and the optional code-on-demand. So the layered system is the only choice that is a REST constraint but not part of the uniform interface, while self-descriptive messages, identification of resources, and HATEOAS are all uniform interface sub-constraints.

Fielding's dissertation enumerates six constraints: Client-Server, Stateless, Cache, Uniform Interface, Layered System, and Code-on-Demand. The question asks the reader to name each and state what it imposes, which is an open recall-and-explain task, so SHORT_ANSWER fits. The grader checks for the six constraint names, and the sample answer gives the concrete requirement each one places on the architecture, including the note that Code-on-Demand is the only optional constraint.

The Richardson Maturity Model defines four levels, each building on the previous one. Level 0 (POX) tunnels everything through HTTP using a single endpoint and POST for every operation. Level 1 introduces individual resource URIs. Level 2 adds correct use of HTTP methods and status codes according to their defined semantics. Level 3 (HATEOAS) adds hypermedia controls so clients discover available state transitions from responses rather than relying on out-of-band knowledge of URIs. The ascending order is therefore Level 0, Level 1, Level 2, Level 3, from least to most REST-conforming.