Intent.AspNetCore.Versioning module applies versioning to your ASP.NET Core services, enabling you to maintain multiple versions of your API simultaneously while evolving your application.
Overview
API versioning is essential for maintaining backward compatibility while introducing new features and changes. This module integrates Microsoft’s ASP.NET Core API Versioning library to provide a robust versioning strategy for your Web APIs.What Gets Generated
ApiVersioningConfiguration
Configures API versioning for your application:ApiVersionSwaggerGenOptions
Integrates versioning with Swagger documentation:Key Features
Multiple Versioning Strategies
URL path, query string, or header-based versioning
Swagger Integration
Separate documentation for each API version
Deprecation Support
Mark old versions as deprecated
Version Discovery
Clients can discover supported versions
Versioning Strategies
URL Path Versioning (Recommended)
Version in the URL path:Query String Versioning
Version in query parameter:Header Versioning
Version in custom header:Media Type Versioning
Version in Accept header:Version Declaration
Single Version
Multiple Versions
Version Neutral
Deprecating Versions
Mark versions as deprecated:Swagger/OpenAPI Integration
Versioning automatically creates separate Swagger documents:API Explorer
Configure API explorer for versioning:Version Discovery
Clients can discover supported versions:Migration Strategies
Breaking Changes
Introduce breaking changes in a new version:Additive Changes
Add new properties without breaking existing clients:Behavioral Changes
Same endpoint, different behavior:Version Routing
Shared Base Route
Custom Routes per Version
Best Practices
Versioning Strategy
Versioning Strategy
- Choose URL path versioning for simplicity and discoverability
- Use semantic versioning (1.0, 2.0, 2.1)
- Don’t version every change - only breaking changes
- Document version differences clearly
Backward Compatibility
Backward Compatibility
- Support at least 2 versions simultaneously
- Give advance notice before deprecating versions
- Provide migration guides for breaking changes
- Use version-neutral endpoints for common functionality
Version Lifecycle
Version Lifecycle
- Start new APIs at v1.0
- Increment major version for breaking changes
- Use minor versions (2.1) for significant non-breaking additions
- Announce deprecation at least 6 months before removal
Client Communication
Client Communication
- Use api-supported-versions header
- Return api-deprecated-versions for old versions
- Include version in error responses
- Provide version-specific documentation
Handling Version Requests
Default Version
Serve default version when unspecified:Version Not Found
Return 400 Bad Request for invalid versions:Testing Versioned APIs
Unit Tests
Integration Tests
Installation
Dependencies
Intent.AspNetCore(>= 5.0.0)Intent.AspNetCore.Controllers(>= 5.2.0)Intent.Modelers.ServicesIntent.Metadata.WebApi
Integration
Automatically integrates with:Intent.AspNetCore.Swashbuckle- Version-aware Swagger documentationIntent.AspNetCore.Scalar- Version-aware Scalar documentation
Next Steps
Swashbuckle
Document multiple API versions
Controllers
Create versioned controllers
Scalar
Modern docs for versioned APIs
