API url paths

[mattfarina]

This is per a conversation with @prydonius in the charts chat meeting.

The current APIs expose the internals for how monocular works. For example, search is at /api/chartsvc/v1/charts/search?q=[term]. This happens via ingress rules that are part of the chart.

In addition to that, the paths produced by the chartsvc are relative to it and don't take into account the ingress rules that prefix the path. For example, a url may look like /v1/assets/banzaicloud-stable/mysql/logo-160x160-fit.png. The full path one needs to access this is actually at /api/chartsvc/v1/assets/banzaicloud-stable/mysql/logo-160x160-fit.png.

While this works when different Monocular components are talking to each other. For when we are only interested in intra-monocular communication.

We now want to expose the search API for other clients, such as the helm client. In exposing an API publicly we now have some new considerations:

• The API needs to last as long as Helm v3 does rather than as long as this major version of Monocular
• Other clients may (will?), I hope, start using the API

To handle these cases I would suggest changes to the URLs we use including:

1. Paths should relate to Monocular and not a current sub-service. (e.g., /api/v1/search instead of /api/chartsvc/v1/charts/search`)
2. Consider if some things from the URL can be removed... for example the current search path lives behind charts/. Is this needed? Would we search for something other than charts?
3. Have the paths returned in the response be full paths relative to the top level domain. (e.g.,
   /v1/assets/banzaicloud-stable/mysql/logo-160x160-fit.png to /api/v1/assets/banzaicloud-stable/mysql/logo-160x160-fit.png

The idea is to consider the UX for an external user of the APIs. In this case we aren't exposing our organizational structure rather trying to provide a targeted API.

Thoughts? Discussion?

[prydonius]

@mattfarina see my comments in #623 (comment) which addresses some of this also.