Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/810
TL;DR: I propose we split this PR into two. The `/bundles` part we can
merge pretty quickly. However, the `/types` and `/subtypes` is too
controversial - it probably deserves a `/v2/` of the REST api.
---
I don't want to lose the word "catalog" in the REST api - it's so good at
getting across the meaning for users! The alternative `/type` is just not as
good, in my opinion.
The multiple endpoints of `/types` and `/subtypes` is confusing. I'd model
the latter as just a filter on `/type`. It would be better achieved with an
additional query parameter rather than a separate endpoint.
If designing a `/v2` REST api, we could use `/catalog` instead of `/type`.
However, it will likely take a while to get to a stable and good `/v2` api.
There are other cleanup/improvements we should probably do to the REST api if
we're releasing a new version of it (e.g. exclude the deprecated stuff, get rid
of `/locations` but figure out if we really need to support locations from
brooklyn.properties, find out from the community about other inconsistencies or
hard-to-understand parts of the api).
The meaning of `GET /subtypes/application` looks completely different from
`GET /catalog/applications`. The latter retrieves the catalog items marked as
`template`, but the new api returns everything that implements `Application`.
Perhaps this is an opportunity to get rid of the "entity" versus "template"
distinction (at least in the REST api). The original meaning/intent of
"template" has entirely changed / been misused! I believe it was originally
intended as a partially-complete YAML blueprint that someone would retrieve via
the REST api, and then modify. They'd then POST their .yaml file to deploy
their app. It has now been used as the list of apps to include in a "quick
launch" view. If designing a new `/v2` api, I'd explicitly support a "quick
launch" list and would get rid of the "template" versus "application" versus
"entity" distinction in the REST api (anywhere you can use an entity, you can
use an app; anywhere you need an app then a non-app entity will be auto-wrapped
in a basic-app).
---
