Skip to content
Back to skills

Api Versioning

ASecurity

Use when versioning Spring MVC or WebFlux APIs in Spring Boot 3 / Spring Framework 6. Covers explicit URL, header, and media-type strategies, compatibility rules, and deprecation handling.

  • 272 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 1, 2026
ai-agentsgojavaspringapi

Works with

  • api

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned September 1, 2026

npx -y skills add rrezartprebreza/spring-boot-skills --skill api-versioning --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Api Versioning?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Api Versioning
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/rrezartprebreza-api-versioning/badge)](https://www.skillsdirectory.com/skills/rrezartprebreza-api-versioning)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: api-versioning
description: >
  Use when versioning Spring MVC or WebFlux APIs in Spring Boot 3 / Spring Framework 6. Covers
  explicit URL, header, and media-type strategies, compatibility rules, and deprecation handling.
---

# API Versioning (Boot 3 / Framework 6)

Boot 3 does not provide Boot 4's built-in mapping `version` attribute. Choose one explicit
strategy and keep it consistent: URL segments, a request header, or media-type parameters.

## Prefer a visible, testable contract

For a public API, `/api/v1/orders` and `/api/v2/orders` are usually the clearest choice. If URLs
must remain stable, resolve a request header at the web boundary and route to versioned handlers.
Do not hide version selection in business services or duplicate it across filters and controllers.

```java
@RestController
@RequestMapping("/api/v1/orders")
class OrderV1Controller {
    @GetMapping("/{id}")
    OrderV1 get(@PathVariable UUID id) { ... }
}
```

Document supported versions in OpenAPI, define a removal policy, and return a consistent error for
unsupported versions. Add `Deprecation`, `Sunset`, and `Link` headers through a response advice or
filter when retiring a version.

## Migration boundary

Keep version-specific DTOs and controllers thin. Map both versions to the same application use
case, and do not copy domain logic into each version. Add contract tests for every supported
version and verify content negotiation if using media types.

## Gotchas

- Agent uses Boot 4's `version` attribute on Boot 3 - it is not available; choose an explicit routing strategy.
- Agent mixes URL, header, and media-type resolution - select one source of truth.
- Agent puts version branching in services - keep compatibility at the web adapter boundary.
- Agent changes response fields without versioning - preserve old contracts or publish a new version.
- Agent invents deprecation headers per controller - centralize them in advice or a filter.
- Agent documents only the latest version - keep OpenAPI and contract tests for every supported version.

Files in this skill

  • SKILL.md2 KB
  • agents/openai.yaml188 B
  • examples/bad-versioned-controller.java190 B
  • examples/good-versioned-controller.java178 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.