1a7cd97099<!-- Provide a brief summary of your changes --> ## Motivation and Context <!-- Why is this change needed? What problem does it solve? --> The following PR adds a new v0.1 API version. The goal is to mark v0.1 as a "freeze" point while keeping v0 as the moving target for new features so integrators can start building on top of something stable(r). Details: * This change is quite simple - we re-register the same handlers twice, once as `v0` and once as `v0.1` * Going forward, we'll keep v0.1 frozen while we add changes either on top of both (non-breaking) or we'll have to branch if breaking changes are necessary * We all acknowledge this is not exactly best-practice, but it gives us a way to gather feedback and allow clients to start integrating with the API without breaking them (**note** this implies a follow up PR that would branch the handlers used in v0.1). * For integrators/clients: please provide your feedback - what works well, what doesn't so we can take this into account going towards GA. ## How Has This Been Tested? <!-- Have you tested this in a real application? Which scenarios were tested? --> ## Breaking Changes <!-- Will users need to update their code or configurations? --> No, this just adds a new API version alongside the existing one. ## Types of changes <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Documentation update ## Checklist <!-- Go over all the following points, and put an `x` in all the boxes that apply. --> - [ ] I have read the [MCP Documentation](https://modelcontextprotocol.io) - [ ] My code follows the repository's style guidelines - [ ] New and existing tests pass locally - [ ] I have added appropriate error handling - [ ] I have added or updated documentation as needed ## Additional context <!-- Add any other context, implementation notes, or design decisions --> Fixes: #649 Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
34 lines
1.3 KiB
Go
34 lines
1.3 KiB
Go
// Package router contains API routing logic
|
|
package router
|
|
|
|
import (
|
|
"github.com/danielgtaylor/huma/v2"
|
|
|
|
v0 "github.com/modelcontextprotocol/registry/internal/api/handlers/v0"
|
|
v0auth "github.com/modelcontextprotocol/registry/internal/api/handlers/v0/auth"
|
|
"github.com/modelcontextprotocol/registry/internal/config"
|
|
"github.com/modelcontextprotocol/registry/internal/service"
|
|
"github.com/modelcontextprotocol/registry/internal/telemetry"
|
|
)
|
|
|
|
func RegisterV0Routes(
|
|
api huma.API, cfg *config.Config, registry service.RegistryService, metrics *telemetry.Metrics,
|
|
) {
|
|
v0.RegisterHealthEndpoint(api, "/v0", cfg, metrics)
|
|
v0.RegisterPingEndpoint(api, "/v0")
|
|
v0.RegisterServersEndpoints(api, "/v0", registry)
|
|
v0.RegisterEditEndpoints(api, "/v0", registry, cfg)
|
|
v0auth.RegisterAuthEndpoints(api, "/v0", cfg)
|
|
v0.RegisterPublishEndpoint(api, "/v0", registry, cfg)
|
|
}
|
|
|
|
func RegisterV0_1Routes(
|
|
api huma.API, cfg *config.Config, registry service.RegistryService, metrics *telemetry.Metrics,
|
|
) {
|
|
v0.RegisterHealthEndpoint(api, "/v0.1", cfg, metrics)
|
|
v0.RegisterPingEndpoint(api, "/v0.1")
|
|
v0.RegisterServersEndpoints(api, "/v0.1", registry)
|
|
v0.RegisterEditEndpoints(api, "/v0.1", registry, cfg)
|
|
v0auth.RegisterAuthEndpoints(api, "/v0.1", cfg)
|
|
v0.RegisterPublishEndpoint(api, "/v0.1", registry, cfg)
|
|
}
|