What is REST and what makes an API RESTful?

REST stands for Representational State Transfer. Roy Fielding's 2000 thesis defined six architectural constraints; in practice, APIs that satisfy most of them are called REST.

The constraints worth knowing:

1. Client-server — separation of concerns. Client UI vs server data; either can evolve independently.
2. Stateless — every request contains all the information needed to process it. The server doesn't keep client session state. Auth tokens travel on every request.
3. Cacheable — responses are explicitly marked cacheable or not (Cache-Control headers). GET is cacheable by default.
4. Uniform interface — resources identified by URLs (/users/42), manipulated via standard HTTP verbs, self-descriptive messages.
5. Layered system — clients can't tell whether they're talking to the origin server, a CDN, or a load balancer. Proxies can be inserted transparently.
6. Code on demand (optional) — server can ship executable code (rare in practice).

The "RESTful API" pattern most teams use:

• URLs are nouns, not verbs. POST /users not POST /createUser.
• HTTP verbs match intent (GET = read, POST = create, …).
• JSON request/response bodies.
• Status codes communicate outcome.
• Plural collection URLs (/users), singular item URLs (/users/42).

Where most "REST APIs" technically aren't strict REST:

• They lack HATEOAS (hypermedia links in responses pointing at next actions). Almost no production API does this rigorously.
• They make stateful POSTs (POST /users/42/activate) — fine practically, not pure REST.

For testers, the practical bar:

• Stateless: each test sets up its own auth; nothing leaks between tests.
• Resource-shaped URLs: predictable to test.
• Standard verbs and status codes: predictable to assert against.

The interview-worthy nuance: REST is a guide, not a religion. Most serious API testers know "what makes an API testable" matters more than "is this strictly REST."