I didn't know you could do `supertype=entity` and it will know that
`entity` is a
supertype corresponding to `o.a.bEntity`.
I do think it makes sense to have `supertype` as a query param.
I've no real objection to this going into /v1/catalog/types.
In short, sounds fine to me, +1 to the chan
Hi Alex, all,
Sounds good.
I (reluctantly) agree to us adding this to `/v1/catalog/types` and
`/v1/catalog/bundles`. The reluctance is because the former is most
definitely intended as a replacement for the existing `/v1/catalog/*` so
should be thought of (and ideally communicated) as a v2. I
Aled, Geoff, All-
I see both /types and /bundles as integral parts of the catalog: you add
and remove bundles and as a result you get types. so i'd like to see
them added to the api together. And /types and /bundles as peers is
more natural to me than `/catalog` returning types and ignoring
I guess I can live with that. It means that /v1/catalog is quite different
from /v2/catalog, but I suppose a difference like that between a /v1 and a
/v2 of an API isn't very remarkable.
what do you say to
/v2/catalog// list every type in the registry (most up to date
version)
/v2/catalo
Hi all,
For `/subtypes` versus `/types`, it's not really about code duplication.
It's that the API is unclear because it's not obvious what the
difference/similarity is. If I saw two endpoints like that (without
looking at the code), I'd assume they were for different things. If I
saw query p
My two cents -
0. Keep /bundles API PR separate from /type and do /bundles now
1. While I like '/catalog' for being more meaningful than '/type', I think
what the type registry does is sufficiently different from the classic
catalog that it needs a new name in the API.
1.1. /type would be my pref
1) like the `/catalog` name and agree with Aled about its power to
communicate the idea
2 & 3) run `/v1` and `/v2` in parallel, with the latter being experimental
and iterative until a 1.0 release
4) no preference
Robert
On 20 September 2017 at 15:45, Alex Heneveld <
alex.henev...@cloudsoftcorp.c
Aled, Thomas, Mark - thanks for the good feedback.
All - There are some good suggestions which I agree deserve discussion.
Specific points.
(1) Should /types and /bundles be top-level or under a /catalog prefix ?
Thomas suggested the latter which also fits. My reason for doing top-level
is simpl
Thanks Alex.
As per my comment in the PR at
https://github.com/apache/brooklyn-server/pull/810#issuecomment-330824643.
---
TL;DR:
Given this is a big API change and given I'm suggesting a `/v2` REST api
then I wanted to raise it on the list as well.
I propose we split this PR into two. The
Hi team-
As mentioned earlier, I've been working on adding bundle support to the
REST API, so we can add/remove/query bundles. And related to this, and
the type registry, is the ability to add arbitrary types but until now
there was no way to query those, so there are endpoints for types/ an
10 matches
Mail list logo
