REST API
REST API is an architectural style for HTTP APIs where resources are identified by URLs and manipulated with standard HTTP methods.
REST (Representational State Transfer) is the dominant architectural style for web APIs. Every entity is a resource with a stable URL. You interact with resources using standard HTTP methods: GET to read, POST to create, PUT or PATCH to update, DELETE to remove. Each request carries all the information the server needs - no session state is stored server-side.
The stateless constraint is what makes REST APIs easy to scale horizontally. Any server can handle any request because there is no session affinity required.
Why it matters in Engineering: REST became the default API style because HTTP is universal. Every language, framework, and platform can issue HTTP requests. REST APIs are straightforward to test, cache, and document. When you integrate with Stripe, Twilio, or Slack, you are calling a REST API. Its main weakness is over-fetching and under-fetching - you often get more data than you need, or have to make multiple round trips to assemble a complete view. That is the problem GraphQL was designed to solve. For service-to-service communication where performance matters more than broad compatibility, gRPC is an alternative worth evaluating. REST APIs are often secured using OAuth 2.0 with JWT bearer tokens.
Core Concepts
Endpoint
A specific URL representing a resource or collection. /users/42 identifies the user with ID 42. /users identifies the collection.
HTTP Methods
GET (read), POST (create), PUT (replace entire resource), PATCH (partial update), DELETE (remove). The method encodes intent - use each one correctly.
Status Codes
200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 500 Internal Server Error. Return the most specific code that accurately describes the outcome.
Idempotency
GET, PUT, and DELETE are idempotent - calling them multiple times produces the same result as calling once. POST is not. This matters when designing retry logic in distributed systems.
Versioning
APIs change. Version via URL path (/v1/users) or request header. Versioning lets you evolve the API without breaking existing clients.