The metadata endpoints are confusingly inconsistent. Lets make them better!
Plan A API:
Plan B API:
- having "dcos" in the api routes or resource paths is redundant
- having both /metadata and /dcos-metadata is confusing
- the /metadata endpoint is a lua generated response, but the /dcos-metadata/* endpoint gives access to any files on a certain location on disk, and the only two files already have specific routes to allow them to be retrieved unauthenticated. So the generic /dcos-metadata/* route is redundant and confusing.
- Amita is adding the version route to the agent node. So now is a good time to refactor away some broken windows instead of copying them.
I'm leaning towards Plan A because:
- version & ui-config are unauthenticated and don't need to be burried for authz reasons.
- version is almost universally top level in APIs I've seen
- /metadata is currently a lua generated non-json response, not a backend component service with multiple paths
- I don't think we need or should have file suffixes on our API endpoints if we can avoid it. This is what mime types in headers are for.
On API reverse compatibility:
- Routes can be moved via either redirect or rewrite. Rewrite is transparent, but redirect also informs the user of the deprecation.
- I prefer redirect, unless we can identify a specific client that doesn't handle redirects or a significant performance impact. If so, we can fallback to rewrite.