What is a RESTful API?
Quick Answer
A RESTful API models the system as resources identified by URLs, manipulated with standard HTTP verbs (GET, POST, PUT, PATCH, DELETE), returning appropriate status codes and representations (usually JSON). It follows REST constraints — statelessness, a uniform interface, cacheability and a client-server split — so any HTTP client can consume it predictably.
A RESTful API treats everything as a resource with a URL, and you act on those resources with the standard HTTP verbs — GET to read, POST to create, PUT or PATCH to update, DELETE to remove — and it returns the right status codes. It follows the REST constraints: it's stateless, so every request carries its own authentication and the server keeps no session; it has a uniform interface, so once you know one endpoint you can guess the others; and responses can declare whether they're cacheable. In practice, doing REST well is mostly about picking the right verb, returning the right status code, having a consistent error format, and having a versioning strategy.
REST is an architectural style. The constraints interviewers expect you to mention:
- Resource-based — nouns in URLs (
/customers/42/orders), not verbs (/getCustomerOrders). - Uniform interface — the same small set of verbs and status codes for everything.
- Stateless — each request carries everything needed (e.g. an auth token); the server keeps no session for the client.
- Cacheable — responses declare their cacheability (
Cache-Control,ETag). - Client-server — the client and server evolve independently behind the contract.
- Layered — proxies, gateways and caches can sit in between transparently.
Practical expectations: correct verbs (GET is safe and idempotent, PUT/DELETE idempotent, POST not), correct status codes (200/201/204/400/401/403/404/409/422/500), consistent error shape, pagination and filtering conventions, and versioning. HATEOAS (links in responses) is the top of the Richardson Maturity Model but rarely required in practice.