API Versioning
Spring Boot 4 versions endpoints for you — no /v1/ copies of every controller, no manual
header parsing.
Enable it
Other strategies:
| Property | Client sends |
|---|---|
spring.mvc.apiversion.use.header=X-API-Version | a header |
spring.mvc.apiversion.use.query-parameter=version | ?version=1.1 |
spring.mvc.apiversion.use.path-segment=1 | /api/1.1/books |
spring.mvc.apiversion.use.media-type-parameter=… | Accept: application/json;version=1.1 |
Reactive apps use spring.webflux.apiversion.*.
Version a mapping
Matching picks the highest version at or below the requested one. A request above every
declared version fails with NotAcceptableApiVersionException → 400.
Tip
1.2+ is the useful default for new endpoints: you write the method once, and it keeps
serving every later version until something actually changes.
Programmatic configuration
For several resolvers at once:
Custom beans take over the details: ApiVersionResolver, ApiVersionParser,
ApiVersionDeprecationHandler (for Deprecation / Sunset headers).
On the client side
RestClient and WebClient can send the version:
Versioning strategy
- version the representation, not every internal change
- additive changes (a new optional field) need no new version
- removing or renaming a field does
- announce deprecation before removal, and delete old versions on a schedule
★ Exercises
- Enable header-based versioning with a default of
1.0. - Serve
/api/books/{id}at1.0and a renamed field at1.1+. - Call both versions with
curland compare the JSON. - Request version
9.9— what status and body come back? - Switch to query-parameter versioning without touching the controllers.