Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: aledsage <git@git.apache.org>
To: dev@brooklyn.apache.org
Reply-To: dev@brooklyn.apache.org
References: <git-pr-810-brooklyn-server@git.apache.org>
In-Reply-To: <git-pr-810-brooklyn-server@git.apache.org>
Subject: [GitHub] brooklyn-server issue #810: REST API for bundles, types, and subtypes
Content-Type: text/plain
Message-Id: <20170920113343.F0EFCF1741@git1-us-west.apache.org>
Date: Wed, 20 Sep 2017 11:33:43 +0000 (UTC)
archived-at: Wed, 20 Sep 2017 11:33:46 -0000

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).


---