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 pull request #810: REST API for bundles, types, and subtypes
Date Fri, 22 Sep 2017 22:02:37 GMT
Github user aledsage commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/810#discussion_r140603081
  
    --- Diff: rest/rest-api/src/main/java/org/apache/brooklyn/rest/api/CatalogApi.java ---
    @@ -153,6 +153,9 @@ public Response createFromUpload(
                 @QueryParam("forceUpdate") @DefaultValue("false")
                         boolean forceUpdate);
         
    +    /** @deprecated since 0.13.0 delete the bundle via DELETE /catalog/bundles/xxx */
    +    // but we will probably keep this around for a while as many places use it
    +    @Deprecated
    --- End diff --
    
    I'm still uncomfortable about the way we're handling our versioning, and with deprecating
`/v1/catalog` methods. To me, the old `/catalog` is the "v1 way of doing it". Once we do a
properly versioned `/v2` then it will be clear that v1 is deprecated (and we'll document it
as such).
    
    But we can go with this for now.
    
    For future work, it would be great if we can get a process in place by which we version
the api in a sensible way: to help people understand what they are using, what is replacing
it, and how/when it will be deprecated.
    
    A big problem with `@Deprecated` here is that I don't think an api user is told about
it at all (it's not even in the swagger), so from the perspective of a rest-api-user it's
as though it's not deprecated.


---

Mime
View raw message