brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-153) REST API Inconsistencies
Date Thu, 02 Jul 2015 11:00:07 GMT


ASF GitHub Bot commented on BROOKLYN-153:

Github user tbouron commented on the pull request:
    `type` is for me the best word here, that's why I used it. I didn't really understand
`symbolicName` at first, not to mention that symbolicName represents something unique to me,
like an ID. 
    FYI, `symbolicName` is actually redundant as the API returns both `type` and `symbolicName`
attributes (which have the same value every time)
    That being said, I do agree that the `brooklyn.catalog.BrooklynCatalog` method's parameters
need to reflect whatever name we choose for the API.

> REST API Inconsistencies
> ------------------------
>                 Key: BROOKLYN-153
>                 URL:
>             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

View raw message