REST API

REST (Representational State Transfer) is an architectural style for designing APIs over HTTP, based on identifiable resources via URLs, standard methods (GET, POST, PUT, DELETE), and representations (JSON, XML). Created by Roy Fielding in 2000, it's the predominant standard for web APIs due to its simplicity, cacheability, and compatibility with existing HTTP infrastructure.

Examples

GET /api/v1/users/42 → { "id": 42, "name": "Alice", "email": "alice@example.com" }
POST /api/v1/users { "name": "Bob", "email": "bob@example.com" } → 201 Created, Location: /api/v1/users/99
PUT /api/v1/users/42 { "name": "Alice Smith" } → 200 OK
DELETE /api/v1/users/42 → 204 No Content
GET /api/v1/posts?author=42&status=published&page=2&limit=20

FAQ

REST is stateless but how do I handle authentication?

Each request includes a token (JWT, OAuth Bearer) in the Authorization header. The server validates the token without maintaining a session; the token contains claims (user ID, permissions). This enables statelessness: any instance can verify the token.

When do I use PUT vs PATCH?

PUT replaces the entire resource; you send all properties. PATCH updates partially; you send only the properties that change. Example: PATCH /users/42 { "email": "new@example.com" } updates only email, leaving the rest intact.

How do I handle relationships in REST?

Three approaches: 1) Subresources: GET /users/42/posts. 2) Query params: GET /posts?user_id=42. 3) Include relations in response: GET /users/42?include=posts (returns user with embedded posts). Choose based on depth and access frequency.

Examples

FAQ

Related generators