Should add an introspection endpoint to know which types are under which api paths

[jwforres]

Currently a UI will have to know whether any given type is under the /api or the /osapi paths. It would be better to be able to introspect a URL on /osapi that tells us the types and the paths for those types.

There may be other things we want to introspect later. We may also want to add a similar introspection endpoint to upstream kubernetes.

[fabianofranz]

That sounds good. Currently the WIP around osc have two rest clients, and every command needs to know who to call.

Proxying all endpoints of /api through /osapi (or vice-versa) could also be an option (much simpler for api consumers).

[fabianofranz]

/CC @liggitt @smarterclayton @jcantrill

[jcantrill]

Is there any reason NOT to have a singular endpoint. OpenShift is supposed to be a value add to k8e. I think it would make more sense to either move our endpoints under the default or alias the k8e endpoints through ours. Isn't k8e supposed to be more about the building blocks anyway, meaning we are more likely to use higher level constructs of OS over k8e going forward. Additionally, I would hope we wouldn't have any overlap since that would be really confusing.

[smarterclayton]

We'll probably punt on doing anything like this until we sort this out upstream in the "ComponentPlugins" issue.

On Oct 17, 2014, at 8:47 AM, Jeff Cantrill notifications@github.com wrote:

Is there any reason NOT to have a singular endpoint. OpenShift is supposed to be a value add to k8e. I think it would make more sense to either move our endpoints under the default or alias the k8e endpoints through ours. Isn't k8e supposed to be more about the building blocks anyway, meaning we are more likely to use higher level constructs of OS over k8e going forward. Additionally, I would hope we wouldn't have any overlap since that would be really confusing.

—
Reply to this email directly or view it on GitHub.

[smarterclayton]

The idea there is something like a single endpoint for all listeners so it should be feasible to do what you're asking. The hard problems are when authorization is inconsistent across endpoints or plugins (which will exist).

[smarterclayton]

Upstream added this - we'll get it when we adopt gorestful

[smarterclayton]

We have this now.