Summary
Add a REST endpoint that allows a Lance REST Namespace implementation to expose its supported capabilities to clients.
A concrete shape could be something like GET /v1/capabilities, returning a structured list of supported features, protocol/version information, and implementation-specific optional behaviors.
Motivation
Today, clients need to assume a certain server behavior from the REST namespace spec version or from implementation-specific knowledge. That makes compatibility harder when:
- different REST namespace implementations support different subsets of behavior
- implementations evolve at different speeds
- clients need to interoperate with multiple namespace backends
A capability discovery endpoint would let clients adapt at runtime instead of relying only on static version assumptions.
Benefits
- Better cross-version compatibility
Clients can distinguish between spec version and actual supported behavior. This makes it easier to support older and newer servers at the same time, and to introduce new optional features without forcing every client/server pair to upgrade in lockstep.
- Client-side fallback / compatibility logic
Clients can inspect the server capabilities and choose compatible code paths or fallback behavior automatically. That would make it easier for different namespace implementations to work correctly behind the same Lance REST Namespace client abstraction.
Why this matters
This would make the REST namespace protocol more resilient across different namespace implementations, and give clients enough information to perform compatibility fallback instead of failing on unsupported behavior.
Summary
Add a REST endpoint that allows a Lance REST Namespace implementation to expose its supported capabilities to clients.
A concrete shape could be something like
GET /v1/capabilities, returning a structured list of supported features, protocol/version information, and implementation-specific optional behaviors.Motivation
Today, clients need to assume a certain server behavior from the REST namespace spec version or from implementation-specific knowledge. That makes compatibility harder when:
A capability discovery endpoint would let clients adapt at runtime instead of relying only on static version assumptions.
Benefits
Clients can distinguish between spec version and actual supported behavior. This makes it easier to support older and newer servers at the same time, and to introduce new optional features without forcing every client/server pair to upgrade in lockstep.
Clients can inspect the server capabilities and choose compatible code paths or fallback behavior automatically. That would make it easier for different namespace implementations to work correctly behind the same Lance REST Namespace client abstraction.
Why this matters
This would make the REST namespace protocol more resilient across different namespace implementations, and give clients enough information to perform compatibility fallback instead of failing on unsupported behavior.