feature: Support for custom subresources on APIResourceSchemas for custom handlers

[mjudeikis]

Feature Description

Currently, kcp works well at proxying standard RESTful APIs. However, there is a growing need to support "functional" subresources on custom APIs that may not follow standard REST patterns.

For example, a user may want to define a VirtualMachine API and add a /connect subresource (.../virtualmachines/my-vm/connect) or a /logs subresource. These endpoints often need to handle custom protocols, such as:

• Streaming log output
• WebSocket connections for an interactive console
• Other custom HTTP-based interactions

There is currently no standard way to declare these types of subresources within kcp's APIResourceSchema and have the kcp front-proxy or API server route traffic for them to the correct backend implementor.

Proposed Solution

We should formally declare custom subresources as part of an APIResourceSchema.

The goal is to:

Allow an API provider to define a custom subresource (e.g., connect, logs, exec) on their APIResourceSchema.

Enable the kcp API server (or front-proxy) to recognise requests for these declared subresources.

Have kcp forward the traffic for that subresource—including the full path and any non-standard REST headers/protocols (like Upgrade for websockets)—to the backend service that implements that specific functionality.

This would allow kcp to act as the central discovery and routing point for all aspects of an API, not just the standard CRUD operations.

Alternative Solutions

No response

Want to contribute?

• I would like to work on this issue.

Additional Context

No response