What is REST?
REST is a style for designing HTTP APIs around resources — nouns like users and orders — that you act on with the standard HTTP verbs. A well-designed REST API is predictable: once you know one endpoint, you can guess the rest. It is still the default for most backend services.
Why it matters
Your API is the contract every client depends on, and changing it later is expensive. Consistent resources, correct verbs, and honest status codes make an API a pleasure to consume and easy to evolve. This is the topic interviewers probe most for backend roles.
What to learn
- Resources and collection vs item URLs
- Mapping verbs to actions: GET, POST, PUT, PATCH, DELETE
- Status codes that match the outcome
- Pagination, filtering, and sorting on collections
- Request validation and consistent error shapes
- Versioning strategies and backward compatibility
- Idempotency for safe retries
Common pitfall
Putting verbs in URLs — /getUser, /createOrder, /deleteThing. The verb is
the HTTP method; the URL names the resource. GET /users/42 and
DELETE /users/42 are the REST way. Verb-in-path APIs are inconsistent and a
clear junior signal.
Resources
Primary (free):
- MDN — HTTP methods · docs
- Microsoft — REST API design best practices · docs
- Postman — What is a REST API? · docs
Practice
Design and build a small CRUD API for one resource — say notes. Implement list with pagination, get-by-id, create, update, and delete, each with the correct verb and status code and a consistent error shape. Test every endpoint with curl. Done when the verbs, URLs, and codes are all consistent.
Outcomes
- Model resources as nouns with collection and item URLs.
- Map each operation to the correct HTTP verb and status code.
- Add pagination, filtering, and a consistent error shape.
- Choose a versioning strategy that preserves backward compatibility.