REST API Masterclass
Architecting Modern Backends01.Home02.What is REST?03.HTTP Deep Dive04.URI Best Practices05.JSON & Data Formats06.Environment Setup07.Your First Resource08.Advanced Controllers09.Database Strategy10.JWT Authentication11.Role-Based Auth (RBAC)12.API Versioning13.Filtering & Searching14.Pagination & Sorting15.Global Error Handling16.Rate Limiting17.CORS & Security18.Swagger & OpenAPI19.Testing with Supertest20.Webhooks & Caching21.Production Checklist
API Versioning
APIs are long-lived. As your business logic evolves, you will eventually need to make Breaking Changes. Versioning allows you to do this without breaking existing client integrations.
1. URI Versioning (Most Popular)
The version is included directly in the URL path. It's easy for developers to see and simple to route.
https://api.example.com/v1/users
https://api.example.com/v2/users2. Header Versioning (Media Type)
The client requests a specific version via the Accept header. This keeps the URI "clean" and resource-oriented.
Accept: application/vnd.example.v2+json3. When to Version?
- Breaking: Changing a field name, removing an endpoint, changing the data structure. (New Version Required)
- Non-Breaking: Adding a new field, adding a new endpoint. (No Version Change Needed)
4. Sunsetting Strategy
Never just turn off an old version. Use the Sunset HTTP header to communicate the date when an endpoint will be removed, and provide clear migration guides.
Best Practice: Don't over-version. Aim to support only the **current** and **previous** major versions (e.g., v2 and v1) to minimize maintenance overhead.