[
https://issues.apache.org/jira/browse/BROOKLYN-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611787#comment-14611787
]
ASF GitHub Bot commented on BROOKLYN-153:
-----------------------------------------
Github user sjcorbett commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/729#issuecomment-117995274
Is "type" the right word for the documentation? It has too many meanings to
be immediately understandable in this context. The methods the arguments are
passed to use "symbolicName" (in brooklyn.catalog.BrooklynCatalog). Are either
better than just "id"?
It's also worth changing the names of the parameters of the implementing
methods in `CatalogResource` to match the interface.
> REST API Inconsistencies
> ------------------------
>
> Key: BROOKLYN-153
> URL: https://issues.apache.org/jira/browse/BROOKLYN-153
> Project: Brooklyn
> Issue Type: Bug
> Affects Versions: 0.7.0
> Reporter: Thomas Bouron
>
> There are inconsistencies with the REST API for the {{/catalog/*}} endpoints.
> For example, If I want to get an application with the a specific {{type}} or
> {{id}}, I can use either:
> {code}
> GET /v1/catalog/entities/{type} (returns the latest version)
> GET /v1/catalog/entities/{id} (returns the specific version as id =
> {type}:{version})
> GET /v1/catalog/application/{id}/{version}
> GET /v1/catalog/entities/{id}:{version}
> GET /v1/catalog/entities/{id}/{version}
> {code}
> This is really confusing, especially the last 3 as the {{id}} already
> contains the {{version}}. These endpoints should rather take the {{type}}
> instead of {{id}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
