Hi Malaka, You need to follow the WSO2 REST API guidelines[1] when designing the API. It will give answers to your concerns also. I think you should start with swagger definitions of the APIs first. We all can verify it then before implementing
[1] - http://wso2.com/whitepapers/wso2-rest-apis-design-guidelines/ Regards, Vinod On Tue, Jun 20, 2017 at 2:44 PM, Pamod Sylvester <[email protected]> wrote: > Hi Malaka, > > Could you elaborate the pros/cons of using either of the conventions ? > > Thanks, > Pamod > > On Tue, Jun 20, 2017 at 2:38 PM, Malaka Gangananda <[email protected]> > wrote: > >> Hi All, >> >> >> >> With MB4 development, we are currently developing REST services to >> support all MB admin services. >> The REST services will built on top of org.wso2.msf4j.feature. The REST >> service component will reside alongside with the broker in the broker >> bundle. So the rest services will be up when EI broker profile is running. >> >> The main resources in MB are the queues, topics, subscriptions and dlc. >> All these resources will be exposed through the REST services. >> The UI/ CLI for MB will be able to use the REST services when managing MB >> resources.So far the security aspect(authorization/authentication) of >> these service are to be decided. >> >> Features Currently Implemented : >> >> 1. >> >> Get messages with/without content in dlc specific to queue >> 2. >> >> Reroute/restore specified messages from dlc to another queue/ >> original queue >> 3. >> >> Reroute/restore all messages from dlc to another queue >> 4. >> >> Get total count of messages in the dlc/under specific queue >> 5. >> >> Get Clustering information of the broker. >> 6. >> >> Get all the destinations that belongs to a destination type. >> 7. >> >> Create/Delete/ a destination. >> 8. >> >> Get details of a destination >> 9. >> >> Purge a queue >> >> >> The proposed URLs for the REST services are available at [1] . >> >> >> >> [1] https://docs.google.com/a/wso2.com/spreadsheets/d/1zWFbkyezo >> 30Rn63QroEf4uc0imlqaEKSj6I_F3buv9g/edit?usp=sharing >> >> >> >> When handling a request we need to handle two types of errors those are >> standard errors such as destination not found exception and application >> level exceptions (for mb andes exception). To handle those two types of >> errors we have used two different approaches. To handle application level >> exceptions we have created a exception class named InternalServerException >> and when application level exception is thrown while handling request we >> would catch the application exception and throw InternalServerException >> with specific message and it will be send as response using exception >> mapper. The standard errors also will be handled in same manner but with >> different exception classes. Also we are going to validate the request >> parameters as well. >> >> >> Concerns : >> 1. The naming convention for the URLs ? >> >> For an example shall we use >> /dlc/{dlc-queue-name}/queue-name/{queue-name} or >> >> /dlc/{dlc-queue-name}/{queue-name} or shall we give >> >> {queue-name} as query parameter >> >> Feedback is appreciated. >> >> Thanks, >> -- >> Malaka. >> -- >> Malaka Gangananda - Software Engineer | WSO2 >> Email : [email protected] >> Mobile : +94713564340 <071%20356%204340> >> Web : http://wso2.com >> <http://wso2.com/signature> >> > > > > -- > *Pamod Sylvester * > > *WSO2 Inc.; http://wso2.com <http://wso2.com>* > cell: +94 77 7779495 <+94%2077%20777%209495> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Vinod Kavinda Senior Software Engineer *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* Mobile : +94 (0) 712 415544 Blog : http://soatechflicks.blogspot.com/ [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
