Hi Hemika, Having a version number (which is separate from the product version number) would be beneficial in my opinion. If there is an API change between releases, this would prevent clients from calling the new API with a client written for an older API. In addition if we have no API changes between consecutive product releases we can keep the same API version as well.
Another option would be to use some kind of an entity representation to expose the API details. For instance when the service root path is invoked we can respond with probable actions client can do on this service with relevant resource urls.From that details client application can use the resource urls provided for browsing queues, browsing subscribers etc. This means the client application won't have hard coded resource paths but will have to use the resource paths provided by the service itself. Take a look at [1][2] for some specifications we can use for this purpose. [1] https://github.com/kevinswiber/siren [2] http://jsonapi.org/format/ Regards, Asitha On Wed, Feb 24, 2016 at 6:24 PM, Hemika Kodikara <hem...@wso2.com> wrote: > Hi All, > > We are planning move all MB admin services which was supported through web > services to REST services. > > The proposed REST services will built on top of org.wso2.msf4j.feature > feature along with Jersey. The REST service component will reside alongside > with the broker in the andes bundle(the broker bundle). Implying that the > REST service component and the andes broker will be in the same bundle. > Having the REST component in a separate bundle would not make sense as the > services rely on the broker and would not work independently. > > The main resources in MB are the queues, topics, durable topics and their > subscriptions. All these resources will be exposed through REST services. > The UI for MB will be using the REST services when managing MB resources. > > So far the security aspect(authorization/authentication) of these service > are yet to be decided. > > Work done so far : > 1. Integrated msf4j feature to MB product. > 2. Created a mock REST service which gets the existing queues from the > broker. > > Features proposed : > 1. Filtering mechanism through query params. > Example : GET /queues?fields=name,messageCount > 2. Pagination for collection(lists) resources. > Example : GET /queues?offset=50&limit=25 > 3. Support JSON only. > > Concerns : > 1. Would we need versioning for this REST service ? Version to be embedded > in the url. > 2. The naming convention for the URLs ? To use underscore or hyphen. > Currently facebook and twitter are using underscore [2]. > > The proposed URLs for the REST services are available at [1]. Only the > services from 3.1.0 are added to this list. > > Feedback is appreciated. > > [1] - > https://docs.google.com/a/wso2.com/spreadsheets/d/1xO40gjTNhQgJnmz7_xZcue1FtQ14IlSdFI0jFIwnsF0/edit?usp=sharing > [2] - http://stackoverflow.com/a/8738518 > > > Regards, > Hemika > > Hemika Kodikara > Software Engineer > WSO2 Inc. > lean . enterprise . middleware > http://wso2.com > > Mobile : +94777688882 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Asitha Nanayakkara* Software Engineer WSO2, Inc. http://wso2.com/ Mob: + 94 77 85 30 682
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
