What makes an API RESTful?

beginner

Re-explain

An API is considered RESTful when it adheres to REST architectural constraints:

Uniform Interface: Consistent resource identification (URLs), manipulation through representations, self-descriptive messages, and HATEOAS
Stateless: Each request is independent and contains all necessary information
Cacheable: Responses indicate whether they can be cached
Client-Server: Clear separation of concerns
Layered System: Can include intermediary layers (proxies, gateways)
Code on Demand (optional): Server can send executable code to client

Additionally, RESTful APIs typically:

Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·

What should the new diagram focus on?

How well did you know this?

AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Most APIs that call themselves REST skip HATEOAS. What does HATEOAS add, and why do teams skip it? Links in responses let clients follow the next valid actions instead of hardcoding URLs. Teams skip it for the effort, and few clients read the links.
Why does statelessness help an API scale, and where does session state live instead? Any server can take any request, so you don't need sticky sessions. State moves to the client, such as a token, or to a shared store like a database or cache.
Which HTTP methods are idempotent, and why does that matter when a client retries? GET, PUT and DELETE are idempotent, POST is not. A client can safely retry an idempotent call. POST needs something extra, like an idempotency key.
How would you make a GET response cacheable, and how does the client check it is still fresh? Cache-Control with max-age, plus an ETag or Last-Modified. The client sends If-None-Match and gets 304 Not Modified if nothing changed.
How would you model an action like cancelling an order without putting a verb in the URL? Treat it as a state change on a resource, like PATCH on the order's status or POST to a cancellation sub-resource. Pick one and say why.

An API is RESTful when it follows the REST architectural constraints. Using HTTP with JSON doesn't get you there by itself.
The central one is the uniform interface. URLs identify resources, clients change them through representations, messages describe themselves, and responses carry links, which is HATEOAS.
Every request is stateless, so it carries everything the server needs, and every response says whether it can be cached.
It's client-server with a clear split of concerns, it can sit behind layers like proxies and gateways, and code on demand is the one optional constraint.
In practice that shows up as noun-based URLs, HTTP methods and status codes used for what they mean, and support for more than one representation, like JSON or XML.
Most APIs called REST skip HATEOAS and have clients hardcode URLs, so strictly they're REST-like. I'd say that openly rather than claim full REST.

Says REST just means HTTP plus JSON REST is a set of architectural constraints, not a protocol or a format. Name the constraints, then show how HTTP methods, URLs and status codes map onto them.
Recites the constraints with no reason for any A memorized list shows recall, not understanding. Say what each one buys, for example statelessness lets any server take any request, and caching cuts load.
Calls a POST-only API with /getUser URLs RESTful That is RPC over HTTP. URLs should name resources as nouns, the HTTP method says what to do, and the status code reports the result.
Claims full REST while ignoring HATEOAS HATEOAS is part of the uniform interface. Admit that most APIs skip it and hardcode URLs, and explain the trade instead of overclaiming.

Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Want a quick review of the fundamentals? See the API Design cheatsheet.

Pro · $10/mo

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.