Rest Services for MB4

[Malaka Gangananda]

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/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_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,

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Pamod Sylvester]

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 <[hidden email]> 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/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_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,

--

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Vinod Kavinda]

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 <[hidden email]> 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 <[hidden email]> 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/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_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,

--

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Malaka Gangananda]

Hi All,

I have attached the pdf of document referred in [1]

 

[1] https://docs.google.com/a/wso2.com/spreadsheets/d/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_F3buv9g/edit?usp=sharing

Thanks,

On Tue, Jun 20, 2017 at 2:44 PM, Pamod Sylvester <[hidden email]> 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 <[hidden email]> 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/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_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,

--

--

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Riyafa Abdul Hameed-2]

Hi Malaka,

Can you provide a class diagram or something similar on the new Exception classes you will be creating for more clarity and to get better suggestion?

Regards,

Riyafa

On Tue, Jun 20, 2017 at 2:57 PM, Malaka Gangananda <[hidden email]> wrote:

Hi All,

I have attached the pdf of document referred in [1]

 

[1] https://docs.google.com/a/wso2.com/spreadsheets/d/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_F3buv9g/edit?usp=sharing

Thanks,

On Tue, Jun 20, 2017 at 2:44 PM, Pamod Sylvester <[hidden email]> 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 <[hidden email]> 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/1zWFbkyezo30Rn63QroEf4uc0imlqaEKSj6I_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,

--

--

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture