adding azeez, Sameera,
 what are your thoughts on having these REST services version-ed.

On Wed, Feb 24, 2016 at 7:03 PM, Asitha Nanayakkara <[email protected]> wrote:
> 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 <[email protected]> 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
>> [email protected]
>> 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
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: [email protected]
P: +94 777542851
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to