brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <...@git.apache.org>
Subject [GitHub] brooklyn-server issue #810: REST API for bundles, types, and subtypes
Date Wed, 20 Sep 2017 11:33:43 GMT
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).


---

Mime
View raw message