REST (Representational State Transfer) is an architectural style for networked applications, defined by Roy Fielding. It isn't a protocol or standard — it's a set of constraints that, when followed, make an API scalable, cacheable, and easy to evolve. A "RESTful" API models everything as resources (users, orders, products) identified by URIs, and manipulates them using standard HTTP methods.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
The URI /users/42 names the resource; GET is the action; JSON is the representation. That combination — nouns in the path, verbs as HTTP methods — is the heart of REST.
REST is the dominant style for web APIs, so interviewers use this question to check that you understand why it works, not just that you can spell it. The two constraints that matter most in practice are statelessness (each request is self-contained, so you can put any number of servers behind a load balancer and scale horizontally without sticky sessions) and the uniform interface (predictable, resource-oriented URLs plus standard HTTP methods and status codes, which means clients don't need custom logic per endpoint). A strong answer connects the constraints to concrete benefits — statelessness enables scaling, cacheability reduces load, the layered system lets you insert CDNs and gateways — and notes that most "REST" APIs are pragmatic rather than fully RESTful (few implement HATEOAS). Understanding these constraints is the foundation for every other REST design decision, from choosing status codes to versioning.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate