API Endpoints

[blkt]

Description

ToolHive Registry must implement two sets of endpoints, one is the official one, the other one are ToolHive-specific extensions

Official Endpoints

• GET /official/v0.1/servers
• GET /official/v0.1/servers/{serverName}/versions
• GET /official/v0.1/servers/{serverName}/versions/{version}
• POST /official/v0.1/publish (must return not-implemented)

The official ones must follow upstream spec.
Consider adding support for an ETag header when implementing the GET /official/v0.1/servers.

Extension Endpoints

• PUT /extension/v0/servers/<id>
• DELETE /extension/v0/servers/<id>

The PUT endpoint must be idempotent.

Scope

This issue concerns itself with

• the implementation of an HTTP server registering empty handlers for these endpoints, and
• the implementation of structs representing the request and response objects
• (optional) glue code for serialization/deserialization

[dmartinol]

Do we really need the official path? BTW: these APIs are instead part of the generic endpoints,: the official API also includes other endpoints that I don't think we want to manage now.

[jhrozek]

Do we really need the official path?

I think the scenario @blkt was trying to avoid was path clashes as the APIs evolve

BTW: these APIs are instead part of the generic endpoints,: the official API also includes other endpoints that I don't think we want to manage now.

We don't want to manage publish (or we want in the sense that we want to return an error right?). What others do we want to avoid?

[blkt]

I'm sorry, I missed the previous notification.

As @jhrozek said, the idea is to avoid clashes, and I don't see other options than rooting the two api sets under separate paths. Most clients accept a base URL which is then used to obtain the full endpoint, so I don't think it's disruptive.

Whether to call them official or something else it's up to debate, and I'm leaning more towards /registry for official API and /extension for the custom API at the moment, but we can discuss.

[blkt]

the official API also includes other endpoints that I don't think we want to manage now.

@dmartinol I assume you're talking about these additional endpoints, am I right?
If yes, I don't know if we're interested in supporting all of those and I don't understand whether they're mandatory or not.