Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Hasitha,
We close the connection from the server side.
Thank you,
Sasikala
On Tue, Jul 10, 2018 at 1:57 PM Hasitha Hiranya wrote:
> Hi Sasikala,
>
> Close Connection - here we close the connection from server side? Or ask
> client to close itself? Former is better, if we can do, because then sever
> has the control of it.
>
> Thanks
>
> On Tue, Jul 10, 2018 at 10:19 AM Sasikala Kottegoda
> wrote:
>
>> Hi all,
>>
>> I am working on adding a separate api for managing AMQP connections.
>> Following are the operations that are planned to be implemented.
>>
>> *Base path: /broker/v1.0/amqp*
>>
>> Operation Method Path Response
>>
>> 1
>> Get All Connection
>> GET
>> /connections
>> HTTP/1.1 200 OK
>> [
>> {
>> connectedIp: "/127.0.0.1:48508",
>> channelCount: 1,
>> connectedTime: 2018-06-21T17:32:28Z
>> },
>> {
>> connectedIp: "/127.0.0.1:48524",
>> channelCount: 2,
>> connectedTime: 2018-06-21T17:32:28Z
>> }
>> ]
>> 2 Close Connection DELETE /connections/{address} HTTP/1.1 200 OK
>> {
>> message: successfuly closed connection
>> }
>> Please provide any feed back on the design. A concern was raised if it is
>> correct to have the *version in the middle of the context*. Is there a
>> better way we can design this since the version is applicable for the
>> broker.
>>
>> I have also attached the swagger.yaml file below.
>>
>> On Thu, Mar 8, 2018 at 11:14 AM Sanjeewa Malalgoda
>> wrote:
>>
>>> +1. That looks good.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera
>>> wrote:
>>>
Hi Sanjeewa,
Thank you for the feedback. Currently, queue purging is a synchronous
call and we are planning to send back the number of messages removed.
Therefore we are planning to use following response format.
HTTP/1.1 200 OK
{
"numberOfMessagesDeleted": 0
}
On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda
wrote:
> If purging is handle by background task and completes sometime after
> response return to client then ideal status code would be 202 Accepted.
> Reason is we really do not know what will happen. All we can say is we
> accepted purging job.
>
> If you do not send response but only send status code after purging we
> should use 204.
>
> Thanks,
> sanjeewa.
>
> On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera
> wrote:
>
>> Hi All,
>>
>> I am working adding queue purge functionality to the admin API. I am
>> thinking of using following design.
>>
>> *Request:*
>>
>> DELETE/queues/*queueName*/messages
>>
>>
>> *Success Response:*
>>
>> HTTP/1.1 200 OK
>>
>>
>> WDYT?
>>
>>
>>
>> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi Asitha/All,
>>>
>>> The paths overall look good to me too and +1 to the
>>> Harsha's suggestion on pagination.
>>>
>>> I have a small suggestion regarding below concern Asitha has
>>> mentioned:
>>>
>>>
>>> I have few concerns regarding deleting bindings. There is no unique
key for the binding hence I was thinking of something like following
for
the delete binding (combination of routing key and queue name is
unique)
*/exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
What about using something like
*/exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
*for
the delete? Can we consider a URI with query params as a unique
resource?
>>>
>>> Shall we introduce a new ID to identify binding? It can be a unique
>>> UUID. This is the approach we have been using in APIM APIs.
>>>
>>> When we create a new binding, the response will include the unique
>>> UUID.
>>>
>>> Eg:
>>>
>>> *Request:*
>>>
>>> POST /exchanges/*exchange1*/bindings
>>> {
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> }
>>>
>>> *Response:*
>>>
>>> HTTP/1.1 201 Created
>>> Location: *https://localhost:9292/admin/1.0
>>> */exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>>
>>> {
>>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> }
>>>
>>>
>>> We can use this ID for next operations with it.
>>>
>>> Eg:
>>>
>>> GET *https://localhost:9292/admin/1.0
>>> */exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>> DELETE *https://localhost:9292/admin/1.0
>>> */exchanges/*
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Sasikala,
Close Connection - here we close the connection from server side? Or ask
client to close itself? Former is better, if we can do, because then sever
has the control of it.
Thanks
On Tue, Jul 10, 2018 at 10:19 AM Sasikala Kottegoda
wrote:
> Hi all,
>
> I am working on adding a separate api for managing AMQP connections.
> Following are the operations that are planned to be implemented.
>
> *Base path: /broker/v1.0/amqp*
>
> Operation Method Path Response
>
> 1
> Get All Connection
> GET
> /connections
> HTTP/1.1 200 OK
> [
> {
> connectedIp: "/127.0.0.1:48508",
> channelCount: 1,
> connectedTime: 2018-06-21T17:32:28Z
> },
> {
> connectedIp: "/127.0.0.1:48524",
> channelCount: 2,
> connectedTime: 2018-06-21T17:32:28Z
> }
> ]
> 2 Close Connection DELETE /connections/{address} HTTP/1.1 200 OK
> {
> message: successfuly closed connection
> }
> Please provide any feed back on the design. A concern was raised if it is
> correct to have the *version in the middle of the context*. Is there a
> better way we can design this since the version is applicable for the
> broker.
>
> I have also attached the swagger.yaml file below.
>
> On Thu, Mar 8, 2018 at 11:14 AM Sanjeewa Malalgoda
> wrote:
>
>> +1. That looks good.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera
>> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>> Thank you for the feedback. Currently, queue purging is a synchronous
>>> call and we are planning to send back the number of messages removed.
>>> Therefore we are planning to use following response format.
>>>
>>> HTTP/1.1 200 OK
>>> {
>>> "numberOfMessagesDeleted": 0
>>> }
>>>
>>>
>>> On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda
>>> wrote:
>>>
If purging is handle by background task and completes sometime after
response return to client then ideal status code would be 202 Accepted.
Reason is we really do not know what will happen. All we can say is we
accepted purging job.
If you do not send response but only send status code after purging we
should use 204.
Thanks,
sanjeewa.
On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera
wrote:
> Hi All,
>
> I am working adding queue purge functionality to the admin API. I am
> thinking of using following design.
>
> *Request:*
>
> DELETE/queues/*queueName*/messages
>
>
> *Success Response:*
>
> HTTP/1.1 200 OK
>
>
> WDYT?
>
>
>
> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe <
> malint...@wso2.com> wrote:
>
>> Hi Asitha/All,
>>
>> The paths overall look good to me too and +1 to the
>> Harsha's suggestion on pagination.
>>
>> I have a small suggestion regarding below concern Asitha has
>> mentioned:
>>
>>
>> I have few concerns regarding deleting bindings. There is no unique
>>> key for the binding hence I was thinking of something like following for
>>> the delete binding (combination of routing key and queue name is unique)
>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>> What about using something like
>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>>> *for
>>> the delete? Can we consider a URI with query params as a unique
>>> resource?
>>>
>>
>> Shall we introduce a new ID to identify binding? It can be a unique
>> UUID. This is the approach we have been using in APIM APIs.
>>
>> When we create a new binding, the response will include the unique
>> UUID.
>>
>> Eg:
>>
>> *Request:*
>>
>> POST /exchanges/*exchange1*/bindings
>> {
>> "routingKey": "routingPattern",
>> "queueName": "myQueue",
>> "filterExpression": "MessageId = 12345"
>> }
>>
>> *Response:*
>>
>> HTTP/1.1 201 Created
>> Location: *https://localhost:9292/admin/1.0
>> */exchanges/*exchange1*/bindings/
>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>
>> {
>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>> "routingKey": "routingPattern",
>> "queueName": "myQueue",
>> "filterExpression": "MessageId = 12345"
>> }
>>
>>
>> We can use this ID for next operations with it.
>>
>> Eg:
>>
>> GET *https://localhost:9292/admin/1.0
>> */exchanges/*exchange1*/bindings/
>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>> DELETE *https://localhost:9292/admin/1.0
>> */exchanges/*exchange1*/bindings/
>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>
>> Also binding list can include each bindings IDs:
>>
>> eg:
>>
>> GET /exchanges/*exchange1*/bindings?offset=20&limit=10
>> {
>>"count": 10,
>>"list": [ {
>> *"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi all,
I am working on adding a separate api for managing AMQP connections.
Following are the operations that are planned to be implemented.
*Base path: /broker/v1.0/amqp*
Operation Method Path Response
1
Get All Connection
GET
/connections
HTTP/1.1 200 OK
[
{
connectedIp: "/127.0.0.1:48508",
channelCount: 1,
connectedTime: 2018-06-21T17:32:28Z
},
{
connectedIp: "/127.0.0.1:48524",
channelCount: 2,
connectedTime: 2018-06-21T17:32:28Z
}
]
2 Close Connection DELETE /connections/{address} HTTP/1.1 200 OK
{
message: successfuly closed connection
}
Please provide any feed back on the design. A concern was raised if it is
correct to have the *version in the middle of the context*. Is there a
better way we can design this since the version is applicable for the
broker.
I have also attached the swagger.yaml file below.
On Thu, Mar 8, 2018 at 11:14 AM Sanjeewa Malalgoda
wrote:
> +1. That looks good.
>
> Thanks,
> sanjeewa.
>
> On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera
> wrote:
>
>> Hi Sanjeewa,
>>
>> Thank you for the feedback. Currently, queue purging is a synchronous
>> call and we are planning to send back the number of messages removed.
>> Therefore we are planning to use following response format.
>>
>> HTTP/1.1 200 OK
>> {
>> "numberOfMessagesDeleted": 0
>> }
>>
>>
>> On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda
>> wrote:
>>
>>> If purging is handle by background task and completes sometime after
>>> response return to client then ideal status code would be 202 Accepted.
>>> Reason is we really do not know what will happen. All we can say is we
>>> accepted purging job.
>>>
>>> If you do not send response but only send status code after purging we
>>> should use 204.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera
>>> wrote:
>>>
Hi All,
I am working adding queue purge functionality to the admin API. I am
thinking of using following design.
*Request:*
DELETE/queues/*queueName*/messages
*Success Response:*
HTTP/1.1 200 OK
WDYT?
On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe <
malint...@wso2.com> wrote:
> Hi Asitha/All,
>
> The paths overall look good to me too and +1 to the
> Harsha's suggestion on pagination.
>
> I have a small suggestion regarding below concern Asitha has mentioned:
>
>
> I have few concerns regarding deleting bindings. There is no unique
>> key for the binding hence I was thinking of something like following for
>> the delete binding (combination of routing key and queue name is unique)
>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>> What about using something like
>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>> *for
>> the delete? Can we consider a URI with query params as a unique resource?
>>
>
> Shall we introduce a new ID to identify binding? It can be a unique
> UUID. This is the approach we have been using in APIM APIs.
>
> When we create a new binding, the response will include the unique
> UUID.
>
> Eg:
>
> *Request:*
>
> POST /exchanges/*exchange1*/bindings
> {
> "routingKey": "routingPattern",
> "queueName": "myQueue",
> "filterExpression": "MessageId = 12345"
> }
>
> *Response:*
>
> HTTP/1.1 201 Created
> Location: *https://localhost:9292/admin/1.0
> */exchanges/*exchange1*/bindings/
> *4a349d47-12fa-490c-bb06-d90610a4897d*
>
> {
> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
> "routingKey": "routingPattern",
> "queueName": "myQueue",
> "filterExpression": "MessageId = 12345"
> }
>
>
> We can use this ID for next operations with it.
>
> Eg:
>
> GET *https://localhost:9292/admin/1.0
> */exchanges/*exchange1*/bindings/
> *4a349d47-12fa-490c-bb06-d90610a4897d*
> DELETE *https://localhost:9292/admin/1.0
> */exchanges/*exchange1*/bindings/
> *4a349d47-12fa-490c-bb06-d90610a4897d*
>
> Also binding list can include each bindings IDs:
>
> eg:
>
> GET /exchanges/*exchange1*/bindings?offset=20&limit=10
> {
>"count": 10,
>"list": [ {
> *"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
> "routingKey": "routingPattern",
> "queueName": "myQueue",
> "filterExpression": "MessageId = 12345"
>},
>{
> *"id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
> "routingKey": "routingPattern2",
> "queueName": "myQueue2",
> "filterExpression": "MessageId = 123456789"
>},
>...
>...
> ],
>"pagination":{
> "total": 134,
> "offset": 20,
>
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
+1. That looks good.
Thanks,
sanjeewa.
On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera wrote:
> Hi Sanjeewa,
>
> Thank you for the feedback. Currently, queue purging is a synchronous call
> and we are planning to send back the number of messages removed. Therefore
> we are planning to use following response format.
>
> HTTP/1.1 200 OK
> {
> "numberOfMessagesDeleted": 0
> }
>
>
> On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda
> wrote:
>
>> If purging is handle by background task and completes sometime after
>> response return to client then ideal status code would be 202 Accepted.
>> Reason is we really do not know what will happen. All we can say is we
>> accepted purging job.
>>
>> If you do not send response but only send status code after purging we
>> should use 204.
>>
>> Thanks,
>> sanjeewa.
>>
>> On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera
>> wrote:
>>
>>> Hi All,
>>>
>>> I am working adding queue purge functionality to the admin API. I am
>>> thinking of using following design.
>>>
>>> *Request:*
>>>
>>> DELETE/queues/*queueName*/messages
>>>
>>>
>>> *Success Response:*
>>>
>>> HTTP/1.1 200 OK
>>>
>>>
>>> WDYT?
>>>
>>>
>>>
>>> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe <
>>> malint...@wso2.com> wrote:
>>>
Hi Asitha/All,
The paths overall look good to me too and +1 to the Harsha's suggestion
on pagination.
I have a small suggestion regarding below concern Asitha has mentioned:
I have few concerns regarding deleting bindings. There is no unique key
> for the binding hence I was thinking of something like following for the
> delete binding (combination of routing key and queue name is unique)
> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
> What about using something like
> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
> *for
> the delete? Can we consider a URI with query params as a unique resource?
>
Shall we introduce a new ID to identify binding? It can be a unique
UUID. This is the approach we have been using in APIM APIs.
When we create a new binding, the response will include the unique UUID.
Eg:
*Request:*
POST /exchanges/*exchange1*/bindings
{
"routingKey": "routingPattern",
"queueName": "myQueue",
"filterExpression": "MessageId = 12345"
}
*Response:*
HTTP/1.1 201 Created
Location: *https://localhost:9292/admin/1.0
*/exchanges/*exchange1*/bindings/
*4a349d47-12fa-490c-bb06-d90610a4897d*
{
* "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
"routingKey": "routingPattern",
"queueName": "myQueue",
"filterExpression": "MessageId = 12345"
}
We can use this ID for next operations with it.
Eg:
GET *https://localhost:9292/admin/1.0
*/exchanges/*exchange1*/bindings/
*4a349d47-12fa-490c-bb06-d90610a4897d*
DELETE *https://localhost:9292/admin/1.0
*/exchanges/*exchange1*/bindings/
*4a349d47-12fa-490c-bb06-d90610a4897d*
Also binding list can include each bindings IDs:
eg:
GET /exchanges/*exchange1*/bindings?offset=20&limit=10
{
"count": 10,
"list": [ {
*"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
"routingKey": "routingPattern",
"queueName": "myQueue",
"filterExpression": "MessageId = 12345"
},
{
*"id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
"routingKey": "routingPattern2",
"queueName": "myQueue2",
"filterExpression": "MessageId = 123456789"
},
...
...
],
"pagination":{
"total": 134,
"offset": 20,
"limit": 10,
"next": "/exchanges/*exchange1*/bindings?offset=30&limit=10",
"previous": "/exchanges/*exchange1*/bindings?offset=10&limit=10"
}
}
Thanks!
On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara
wrote:
>
>
> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> Taking all the concerns discussed in to account I did some updates on
>> the design.
>>
>> With this design, I'll be exposing the exchanges, bindings, queues,
>> and consumers. This is to avoid confusion in coming up with a design to
>> expose topics (pub-sub pattern) as a first-class citizen (Since it is
>> another exchange within the broker).
>>
>> Following is the updated design
>>
>>
>> Base path /broker/v.1.0
>>
>>
>>
>>
>>
>>
>>
>> Queues
>>
>>
>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
>> true, "autoDelete": false
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Sanjeewa,
Thank you for the feedback. Currently, queue purging is a synchronous call
and we are planning to send back the number of messages removed. Therefore
we are planning to use following response format.
HTTP/1.1 200 OK
{
"numberOfMessagesDeleted": 0
}
On Thu, Mar 8, 2018 at 10:41 AM, Sanjeewa Malalgoda
wrote:
> If purging is handle by background task and completes sometime after
> response return to client then ideal status code would be 202 Accepted.
> Reason is we really do not know what will happen. All we can say is we
> accepted purging job.
>
> If you do not send response but only send status code after purging we
> should use 204.
>
> Thanks,
> sanjeewa.
>
> On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera
> wrote:
>
>> Hi All,
>>
>> I am working adding queue purge functionality to the admin API. I am
>> thinking of using following design.
>>
>> *Request:*
>>
>> DELETE/queues/*queueName*/messages
>>
>>
>> *Success Response:*
>>
>> HTTP/1.1 200 OK
>>
>>
>> WDYT?
>>
>>
>>
>> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi Asitha/All,
>>>
>>> The paths overall look good to me too and +1 to the Harsha's suggestion
>>> on pagination.
>>>
>>> I have a small suggestion regarding below concern Asitha has mentioned:
>>>
>>>
>>> I have few concerns regarding deleting bindings. There is no unique key
for the binding hence I was thinking of something like following for the
delete binding (combination of routing key and queue name is unique)
*/exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
What about using something like
*/exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
*for
the delete? Can we consider a URI with query params as a unique resource?
>>>
>>> Shall we introduce a new ID to identify binding? It can be a unique
>>> UUID. This is the approach we have been using in APIM APIs.
>>>
>>> When we create a new binding, the response will include the unique UUID.
>>>
>>> Eg:
>>>
>>> *Request:*
>>>
>>> POST /exchanges/*exchange1*/bindings
>>> {
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> }
>>>
>>> *Response:*
>>>
>>> HTTP/1.1 201 Created
>>> Location: *https://localhost:9292/admin/1.0
>>> */exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>>
>>> {
>>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>> }
>>>
>>>
>>> We can use this ID for next operations with it.
>>>
>>> Eg:
>>>
>>> GET *https://localhost:9292/admin/1.0
>>> */exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>> DELETE *https://localhost:9292/admin/1.0
>>> */exchanges/*exchange1*/bindings/
>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>>
>>> Also binding list can include each bindings IDs:
>>>
>>> eg:
>>>
>>> GET /exchanges/*exchange1*/bindings?offset=20&limit=10
>>> {
>>>"count": 10,
>>>"list": [ {
>>> *"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>>> "routingKey": "routingPattern",
>>> "queueName": "myQueue",
>>> "filterExpression": "MessageId = 12345"
>>>},
>>>{
>>> *"id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
>>> "routingKey": "routingPattern2",
>>> "queueName": "myQueue2",
>>> "filterExpression": "MessageId = 123456789"
>>>},
>>>...
>>>...
>>> ],
>>>"pagination":{
>>> "total": 134,
>>> "offset": 20,
>>> "limit": 10,
>>> "next": "/exchanges/*exchange1*/bindings?offset=30&limit=10",
>>> "previous": "/exchanges/*exchange1*/bindings?offset=10&limit=10"
>>>}
>>> }
>>>
>>> Thanks!
>>>
>>> On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara
>>> wrote:
>>>
On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
wrote:
> Hi all,
>
> Taking all the concerns discussed in to account I did some updates on
> the design.
>
> With this design, I'll be exposing the exchanges, bindings, queues,
> and consumers. This is to avoid confusion in coming up with a design to
> expose topics (pub-sub pattern) as a first-class citizen (Since it is
> another exchange within the broker).
>
> Following is the updated design
>
>
> Base path /broker/v.1.0
>
>
>
>
>
>
>
> Queues
>
>
> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
> true, "autoDelete": false }
> 6 List Queues/Topics GET /queues
> 7 Get Queue Details GET /queues/{queueName}
> 8 Delete Queue DELETE /queues/{queueName}
>
>
>
>
>
>
> Subscriptions for a queue or topic
>
>
> 9 List subscriptions for a destination GET
> /queues/{
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
If purging is handle by background task and completes sometime after
response return to client then ideal status code would be 202 Accepted.
Reason is we really do not know what will happen. All we can say is we
accepted purging job.
If you do not send response but only send status code after purging we
should use 204.
Thanks,
sanjeewa.
On Thu, Mar 8, 2018 at 8:49 AM, Asanka Abeyweera wrote:
> Hi All,
>
> I am working adding queue purge functionality to the admin API. I am
> thinking of using following design.
>
> *Request:*
>
> DELETE/queues/*queueName*/messages
>
>
> *Success Response:*
>
> HTTP/1.1 200 OK
>
>
> WDYT?
>
>
>
> On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe > wrote:
>
>> Hi Asitha/All,
>>
>> The paths overall look good to me too and +1 to the Harsha's suggestion
>> on pagination.
>>
>> I have a small suggestion regarding below concern Asitha has mentioned:
>>
>>
>> I have few concerns regarding deleting bindings. There is no unique key
>>> for the binding hence I was thinking of something like following for the
>>> delete binding (combination of routing key and queue name is unique)
>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>> What about using something like
>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>>> *for
>>> the delete? Can we consider a URI with query params as a unique resource?
>>>
>>
>> Shall we introduce a new ID to identify binding? It can be a unique UUID.
>> This
>> is the approach we have been using in APIM APIs.
>>
>> When we create a new binding, the response will include the unique UUID.
>>
>> Eg:
>>
>> *Request:*
>>
>> POST /exchanges/*exchange1*/bindings
>> {
>> "routingKey": "routingPattern",
>> "queueName": "myQueue",
>> "filterExpression": "MessageId = 12345"
>> }
>>
>> *Response:*
>>
>> HTTP/1.1 201 Created
>> Location: *https://localhost:9292/admin/1.0
>> */exchanges/*exchange1*/bindings/
>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>
>> {
>> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>> "routingKey": "routingPattern",
>> "queueName": "myQueue",
>> "filterExpression": "MessageId = 12345"
>> }
>>
>>
>> We can use this ID for next operations with it.
>>
>> Eg:
>>
>> GET *https://localhost:9292/admin/1.0 *
>> /exchanges/*exchange1*/bindings/*4a349d47-12fa-490c-bb06-d90610a4897d*
>> DELETE *https://localhost:9292/admin/1.0
>> */exchanges/*exchange1*/bindings/
>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>
>> Also binding list can include each bindings IDs:
>>
>> eg:
>>
>> GET /exchanges/*exchange1*/bindings?offset=20&limit=10
>> {
>>"count": 10,
>>"list": [ {
>> *"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
>> "routingKey": "routingPattern",
>> "queueName": "myQueue",
>> "filterExpression": "MessageId = 12345"
>>},
>>{
>> *"id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
>> "routingKey": "routingPattern2",
>> "queueName": "myQueue2",
>> "filterExpression": "MessageId = 123456789"
>>},
>>...
>>...
>> ],
>>"pagination":{
>> "total": 134,
>> "offset": 20,
>> "limit": 10,
>> "next": "/exchanges/*exchange1*/bindings?offset=30&limit=10",
>> "previous": "/exchanges/*exchange1*/bindings?offset=10&limit=10"
>>}
>> }
>>
>> Thanks!
>>
>> On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara wrote:
>>
>>>
>>>
>>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
>>> wrote:
>>>
Hi all,
Taking all the concerns discussed in to account I did some updates on
the design.
With this design, I'll be exposing the exchanges, bindings, queues, and
consumers. This is to avoid confusion in coming up with a design to expose
topics (pub-sub pattern) as a first-class citizen (Since it is another
exchange within the broker).
Following is the updated design
Base path /broker/v.1.0
Queues
5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
true, "autoDelete": false }
6 List Queues/Topics GET /queues
7 Get Queue Details GET /queues/{queueName}
8 Delete Queue DELETE /queues/{queueName}
Subscriptions for a queue or topic
9 List subscriptions for a destination GET
/queues/{queueName}/consumers
10 Get subscriber details GET /queues/{queueName}/consumers/
{consumerTag}
11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
Exchanges
1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
"amq.direct", "durable": true }
2 Get All exchanges GET /exchanges
3 Get Exchange GET /exchanges/{exchangeName}
4 Delete Exchange DELETE /exchanges/{exchangeName}
Bindings
>>
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi All,
I am working adding queue purge functionality to the admin API. I am
thinking of using following design.
*Request:*
DELETE/queues/*queueName*/messages
*Success Response:*
HTTP/1.1 200 OK
WDYT?
On Wed, Jan 17, 2018 at 10:41 AM, Malintha Amarasinghe
wrote:
> Hi Asitha/All,
>
> The paths overall look good to me too and +1 to the Harsha's suggestion on
> pagination.
>
> I have a small suggestion regarding below concern Asitha has mentioned:
>
>
> I have few concerns regarding deleting bindings. There is no unique key
>> for the binding hence I was thinking of something like following for the
>> delete binding (combination of routing key and queue name is unique)
>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>> What about using something like
>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>> *for
>> the delete? Can we consider a URI with query params as a unique resource?
>>
>
> Shall we introduce a new ID to identify binding? It can be a unique UUID. This
> is the approach we have been using in APIM APIs.
>
> When we create a new binding, the response will include the unique UUID.
>
> Eg:
>
> *Request:*
>
> POST /exchanges/*exchange1*/bindings
> {
> "routingKey": "routingPattern",
> "queueName": "myQueue",
> "filterExpression": "MessageId = 12345"
> }
>
> *Response:*
>
> HTTP/1.1 201 Created
> Location: *https://localhost:9292/admin/1.0
> */exchanges/*exchange1*/bindings/
> *4a349d47-12fa-490c-bb06-d90610a4897d*
>
> {
> * "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
> "routingKey": "routingPattern",
> "queueName": "myQueue",
> "filterExpression": "MessageId = 12345"
> }
>
>
> We can use this ID for next operations with it.
>
> Eg:
>
> GET *https://localhost:9292/admin/1.0 */
> exchanges/*exchange1*/bindings/*4a349d47-12fa-490c-bb06-d90610a4897d*
> DELETE *https://localhost:9292/admin/1.0
> */exchanges/*exchange1*/bindings/
> *4a349d47-12fa-490c-bb06-d90610a4897d*
>
> Also binding list can include each bindings IDs:
>
> eg:
>
> GET /exchanges/*exchange1*/bindings?offset=20&limit=10
> {
>"count": 10,
>"list": [ {
> *"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
> "routingKey": "routingPattern",
> "queueName": "myQueue",
> "filterExpression": "MessageId = 12345"
>},
>{
> *"id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
> "routingKey": "routingPattern2",
> "queueName": "myQueue2",
> "filterExpression": "MessageId = 123456789"
>},
>...
>...
> ],
>"pagination":{
> "total": 134,
> "offset": 20,
> "limit": 10,
> "next": "/exchanges/*exchange1*/bindings?offset=30&limit=10",
> "previous": "/exchanges/*exchange1*/bindings?offset=10&limit=10"
>}
> }
>
> Thanks!
>
> On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara wrote:
>
>>
>>
>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
>> wrote:
>>
>>> Hi all,
>>>
>>> Taking all the concerns discussed in to account I did some updates on
>>> the design.
>>>
>>> With this design, I'll be exposing the exchanges, bindings, queues, and
>>> consumers. This is to avoid confusion in coming up with a design to expose
>>> topics (pub-sub pattern) as a first-class citizen (Since it is another
>>> exchange within the broker).
>>>
>>> Following is the updated design
>>>
>>>
>>> Base path /broker/v.1.0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Queues
>>>
>>>
>>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
>>> true, "autoDelete": false }
>>> 6 List Queues/Topics GET /queues
>>> 7 Get Queue Details GET /queues/{queueName}
>>> 8 Delete Queue DELETE /queues/{queueName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> Subscriptions for a queue or topic
>>>
>>>
>>> 9 List subscriptions for a destination GET /queues/{queueName}/consumers
>>> 10 Get subscriber details GET /queues/{queueName}/consumers/
>>> {consumerTag}
>>> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>>>
>>>
>>>
>>>
>>>
>>>
>>> Exchanges
>>>
>>>
>>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>>> "amq.direct", "durable": true }
>>> 2 Get All exchanges GET /exchanges
>>> 3 Get Exchange GET /exchanges/{exchangeName}
>>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> Bindings
>>>
>>>
>>>
>>> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>>>
>>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
>>> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
>>> 12345"}
>>>
>>> Delete binding DELETE /exchanges/{exchangeName}/bind
>>> ings/{routingKey}/{queueName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> I have few concerns regarding deleting bindings. There is no unique key
>>> for the binding hence I was thinking of something like following for the
>>> delete binding (combination of routing key and queue name is unique)
>>> */exchan
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Asitha/All,
The paths overall look good to me too and +1 to the Harsha's suggestion on
pagination.
I have a small suggestion regarding below concern Asitha has mentioned:
I have few concerns regarding deleting bindings. There is no unique key for
> the binding hence I was thinking of something like following for the delete
> binding (combination of routing key and queue name is unique)
> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
> What about using something like
> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234 *for
> the delete? Can we consider a URI with query params as a unique resource?
>
Shall we introduce a new ID to identify binding? It can be a unique UUID. This
is the approach we have been using in APIM APIs.
When we create a new binding, the response will include the unique UUID.
Eg:
*Request:*
POST /exchanges/*exchange1*/bindings
{
"routingKey": "routingPattern",
"queueName": "myQueue",
"filterExpression": "MessageId = 12345"
}
*Response:*
HTTP/1.1 201 Created
Location: *https://localhost:9292/admin/1.0
*/exchanges/*exchange1*/bindings/
*4a349d47-12fa-490c-bb06-d90610a4897d*
{
* "id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
"routingKey": "routingPattern",
"queueName": "myQueue",
"filterExpression": "MessageId = 12345"
}
We can use this ID for next operations with it.
Eg:
GET *https://localhost:9292/admin/1.0 */
exchanges/*exchange1*/bindings/*4a349d47-12fa-490c-bb06-d90610a4897d*
DELETE *https://localhost:9292/admin/1.0 *
/exchanges/*exchange1*/bindings/*4a349d47-12fa-490c-bb06-d90610a4897d*
Also binding list can include each bindings IDs:
eg:
GET /exchanges/*exchange1*/bindings?offset=20&limit=10
{
"count": 10,
"list": [ {
*"id" : "4a349d47-12fa-490c-bb06-d90610a4897d"*
"routingKey": "routingPattern",
"queueName": "myQueue",
"filterExpression": "MessageId = 12345"
},
{
*"id" : "d6cf5769-33a1-48e7-b9fd-3db8580292e0"*
"routingKey": "routingPattern2",
"queueName": "myQueue2",
"filterExpression": "MessageId = 123456789"
},
...
...
],
"pagination":{
"total": 134,
"offset": 20,
"limit": 10,
"next": "/exchanges/*exchange1*/bindings?offset=30&limit=10",
"previous": "/exchanges/*exchange1*/bindings?offset=10&limit=10"
}
}
Thanks!
On Mon, Jan 15, 2018 at 10:49 PM, Harsha Kumara wrote:
>
>
> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> Taking all the concerns discussed in to account I did some updates on the
>> design.
>>
>> With this design, I'll be exposing the exchanges, bindings, queues, and
>> consumers. This is to avoid confusion in coming up with a design to expose
>> topics (pub-sub pattern) as a first-class citizen (Since it is another
>> exchange within the broker).
>>
>> Following is the updated design
>>
>>
>> Base path /broker/v.1.0
>>
>>
>>
>>
>>
>>
>>
>> Queues
>>
>>
>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
>> true, "autoDelete": false }
>> 6 List Queues/Topics GET /queues
>> 7 Get Queue Details GET /queues/{queueName}
>> 8 Delete Queue DELETE /queues/{queueName}
>>
>>
>>
>>
>>
>>
>> Subscriptions for a queue or topic
>>
>>
>> 9 List subscriptions for a destination GET /queues/{queueName}/consumers
>> 10 Get subscriber details GET /queues/{queueName}/consumers/{consumerTag}
>> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>>
>>
>>
>>
>>
>>
>> Exchanges
>>
>>
>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>> "amq.direct", "durable": true }
>> 2 Get All exchanges GET /exchanges
>> 3 Get Exchange GET /exchanges/{exchangeName}
>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>
>>
>>
>>
>>
>>
>> Bindings
>>
>>
>>
>> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>>
>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
>> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
>> 12345"}
>>
>> Delete binding DELETE /exchanges/{exchangeName}/bind
>> ings/{routingKey}/{queueName}
>>
>>
>>
>>
>>
>>
>> I have few concerns regarding deleting bindings. There is no unique key
>> for the binding hence I was thinking of something like following for the
>> delete binding (combination of routing key and queue name is unique)
>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>
>> What about using something like
>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>> *for the delete? Can we consider a URI with query params as a unique
>> resource?
>>
>> I have attached the swagger file for the API as well.
>>
> Attached swagger is looks fine. You will need to add the details about
> authetication schemes in to the swagger itself which will be useful. Also
> the results which returns lists such as queues will be requir
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara wrote:
> Hi all,
>
> Taking all the concerns discussed in to account I did some updates on the
> design.
>
> With this design, I'll be exposing the exchanges, bindings, queues, and
> consumers. This is to avoid confusion in coming up with a design to expose
> topics (pub-sub pattern) as a first-class citizen (Since it is another
> exchange within the broker).
>
> Following is the updated design
>
>
> Base path /broker/v.1.0
>
>
>
>
>
>
>
> Queues
>
>
> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
> true, "autoDelete": false }
> 6 List Queues/Topics GET /queues
> 7 Get Queue Details GET /queues/{queueName}
> 8 Delete Queue DELETE /queues/{queueName}
>
>
>
>
>
>
> Subscriptions for a queue or topic
>
>
> 9 List subscriptions for a destination GET /queues/{queueName}/consumers
> 10 Get subscriber details GET /queues/{queueName}/consumers/{consumerTag}
> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>
>
>
>
>
>
> Exchanges
>
>
> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
> "amq.direct", "durable": true }
> 2 Get All exchanges GET /exchanges
> 3 Get Exchange GET /exchanges/{exchangeName}
> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>
>
>
>
>
>
> Bindings
>
>
>
> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>
> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
> 12345"}
>
> Delete binding DELETE /exchanges/{exchangeName}/bindings/{routingKey}/{
> queueName}
>
>
>
>
>
>
> I have few concerns regarding deleting bindings. There is no unique key
> for the binding hence I was thinking of something like following for the
> delete binding (combination of routing key and queue name is unique)
> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>
> What about using something like
> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
> *for the delete? Can we consider a URI with query params as a unique
> resource?
>
> I have attached the swagger file for the API as well.
>
Attached swagger is looks fine. You will need to add the details about
authetication schemes in to the swagger itself which will be useful. Also
the results which returns lists such as queues will be required to have
pagination. In APIM we are using separate pagination context in response as
follow.
{
"count": 2,
...
...
"pagination": {
"total": 4,
"offset": 0,
"limit": 2
}
}
>
>
> Regards,
> Asitha
>
>
> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera
> wrote:
>
>> Hi Asitha,
>>
>> I think it is better to say queues rather than destinations since the
>> actions mean different things in queues and topics. For example,
>>
>>- Create
>> - Queues - we can create the queue in broker core. This will be
>> useful in assigning permissions
>> - Topics - We can't do anything at broker code. Corresponding
>> queues will depend on the subscription id if durable, random name if
>> non
>> durable.
>>- Search
>>- Queues - we can return queues matching the search criteria
>> - Topics - It's hard to decide what to return since their can be
>> unlimited number of options.
>>- Delete
>> - Queues - we can delete the specified queues
>> - Topics - Again bit ambiguous what to delete. Maybe we can go
>> through the matching bindings and delete the matching queues. My
>> opinion is
>> we should not do such a thing.
>>
>> Addtionally when we are desiging the REST API better if we dont expose
>> functionalities that we are expecting to expose through the HTTP transport.
>> I think the main objective in the first iteration should be to assist the
>> users in debugging issues. Some information that a user might need is,
>>
>>- Queue list
>>- Subscriptions for a given queue
>>- Queue details - number messages etc
>>- Message details
>>- Permission details
>>- Binding details of a queue. Will be very useful for topic scenarios.
>>
>>
>> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
>> wrote:
>>
>>> Hi Asitha,
>>>
>>> Thanks for the explanation.
>>>
>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
>>> wrote:
>>>
Hi Eranda,
On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
wrote:
> Hi all,
>
> Small addition to the Malintha's suggestion, I think a binding should
> be a 3-tuple element
>
For Bindings, we'll be using queue-name, routing-key, and filters.
Exchange name can be inferred since we define bindings for a given
exchange.
>>> +1
>>>
> Also, is it correct to use the term "destination" to generalize queues
> and topics? AFAIK it's coming from the JMS world.
>
Yes, If we are going with a separate path for queues, outside
/exchanges, w
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Vinod,
Updating queues, bindings, and exchanges are invalid scenarios in AMQP
model.
On Fri, Jan 12, 2018 at 1:57 PM, Vinod Kavinda wrote:
> Hi Asitha,
> Don't we need APIs to update the existing Queues and Exchanges? This can
> be achieved by the *PUT *method.
>
> Regards,
> Vinod
>
> On Fri, Jan 12, 2018 at 11:22 AM, Asitha Nanayakkara
> wrote:
>
>> +1. At the moment we don't have that feature implemented within broker
>> core. I have created an issue [1] to track this.
>>
>> [1] https://github.com/wso2/message-broker/issues/142
>>
>>
>> On Fri, Jan 12, 2018 at 10:02 AM, Hasitha Hiranya
>> wrote:
>>
>>> Hi Asitha,
>>>
>>> We need a API to purge a queue as well.
>>>
>>> Thanks
>>>
>>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
>>> wrote:
>>>
Hi all,
Taking all the concerns discussed in to account I did some updates on
the design.
With this design, I'll be exposing the exchanges, bindings, queues, and
consumers. This is to avoid confusion in coming up with a design to expose
topics (pub-sub pattern) as a first-class citizen (Since it is another
exchange within the broker).
Following is the updated design
Base path /broker/v.1.0
Queues
5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
true, "autoDelete": false }
6 List Queues/Topics GET /queues
7 Get Queue Details GET /queues/{queueName}
8 Delete Queue DELETE /queues/{queueName}
Subscriptions for a queue or topic
9 List subscriptions for a destination GET
/queues/{queueName}/consumers
10 Get subscriber details GET /queues/{queueName}/consumers/
{consumerTag}
11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
Exchanges
1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
"amq.direct", "durable": true }
2 Get All exchanges GET /exchanges
3 Get Exchange GET /exchanges/{exchangeName}
4 Delete Exchange DELETE /exchanges/{exchangeName}
Bindings
List bindings for exchange GET /exchanges/{exchangeName}/bindings
Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
"routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
12345"}
Delete binding DELETE /exchanges/{exchangeName}/bind
ings/{routingKey}/{queueName}
I have few concerns regarding deleting bindings. There is no unique key
for the binding hence I was thinking of something like following for the
delete binding (combination of routing key and queue name is unique)
*/exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
What about using something like
*/exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
*for the delete? Can we consider a URI with query params as a unique
resource?
I have attached the swagger file for the API as well.
Regards,
Asitha
On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera
wrote:
> Hi Asitha,
>
> I think it is better to say queues rather than destinations since the
> actions mean different things in queues and topics. For example,
>
>- Create
> - Queues - we can create the queue in broker core. This will be
> useful in assigning permissions
> - Topics - We can't do anything at broker code. Corresponding
> queues will depend on the subscription id if durable, random name
> if non
> durable.
>- Search
>- Queues - we can return queues matching the search criteria
> - Topics - It's hard to decide what to return since their can
> be unlimited number of options.
>- Delete
> - Queues - we can delete the specified queues
> - Topics - Again bit ambiguous what to delete. Maybe we can go
> through the matching bindings and delete the matching queues. My
> opinion is
> we should not do such a thing.
>
> Addtionally when we are desiging the REST API better if we dont expose
> functionalities that we are expecting to expose through the HTTP
> transport.
> I think the main objective in the first iteration should be to assist the
> users in debugging issues. Some information that a user might need is,
>
>- Queue list
>- Subscriptions for a given queue
>- Queue details - number messages etc
>- Message details
>- Permission details
>- Binding details of a queue. Will be very useful for topic
>scenarios.
>
>
> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
> wrote:
>
>> Hi Asitha,
>>
>> Thanks
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Asitha,
Don't we need APIs to update the existing Queues and Exchanges? This can be
achieved by the *PUT *method.
Regards,
Vinod
On Fri, Jan 12, 2018 at 11:22 AM, Asitha Nanayakkara
wrote:
> +1. At the moment we don't have that feature implemented within broker
> core. I have created an issue [1] to track this.
>
> [1] https://github.com/wso2/message-broker/issues/142
>
>
> On Fri, Jan 12, 2018 at 10:02 AM, Hasitha Hiranya
> wrote:
>
>> Hi Asitha,
>>
>> We need a API to purge a queue as well.
>>
>> Thanks
>>
>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
>> wrote:
>>
>>> Hi all,
>>>
>>> Taking all the concerns discussed in to account I did some updates on
>>> the design.
>>>
>>> With this design, I'll be exposing the exchanges, bindings, queues, and
>>> consumers. This is to avoid confusion in coming up with a design to expose
>>> topics (pub-sub pattern) as a first-class citizen (Since it is another
>>> exchange within the broker).
>>>
>>> Following is the updated design
>>>
>>>
>>> Base path /broker/v.1.0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Queues
>>>
>>>
>>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
>>> true, "autoDelete": false }
>>> 6 List Queues/Topics GET /queues
>>> 7 Get Queue Details GET /queues/{queueName}
>>> 8 Delete Queue DELETE /queues/{queueName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> Subscriptions for a queue or topic
>>>
>>>
>>> 9 List subscriptions for a destination GET /queues/{queueName}/consumers
>>> 10 Get subscriber details GET /queues/{queueName}/consumers/
>>> {consumerTag}
>>> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>>>
>>>
>>>
>>>
>>>
>>>
>>> Exchanges
>>>
>>>
>>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>>> "amq.direct", "durable": true }
>>> 2 Get All exchanges GET /exchanges
>>> 3 Get Exchange GET /exchanges/{exchangeName}
>>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> Bindings
>>>
>>>
>>>
>>> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>>>
>>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
>>> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
>>> 12345"}
>>>
>>> Delete binding DELETE /exchanges/{exchangeName}/bind
>>> ings/{routingKey}/{queueName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> I have few concerns regarding deleting bindings. There is no unique key
>>> for the binding hence I was thinking of something like following for the
>>> delete binding (combination of routing key and queue name is unique)
>>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>>
>>> What about using something like
>>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>>> *for the delete? Can we consider a URI with query params as a unique
>>> resource?
>>>
>>> I have attached the swagger file for the API as well.
>>>
>>> Regards,
>>> Asitha
>>>
>>>
>>> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera
>>> wrote:
>>>
Hi Asitha,
I think it is better to say queues rather than destinations since the
actions mean different things in queues and topics. For example,
- Create
- Queues - we can create the queue in broker core. This will be
useful in assigning permissions
- Topics - We can't do anything at broker code. Corresponding
queues will depend on the subscription id if durable, random name if
non
durable.
- Search
- Queues - we can return queues matching the search criteria
- Topics - It's hard to decide what to return since their can be
unlimited number of options.
- Delete
- Queues - we can delete the specified queues
- Topics - Again bit ambiguous what to delete. Maybe we can go
through the matching bindings and delete the matching queues. My
opinion is
we should not do such a thing.
Addtionally when we are desiging the REST API better if we dont expose
functionalities that we are expecting to expose through the HTTP transport.
I think the main objective in the first iteration should be to assist the
users in debugging issues. Some information that a user might need is,
- Queue list
- Subscriptions for a given queue
- Queue details - number messages etc
- Message details
- Permission details
- Binding details of a queue. Will be very useful for topic
scenarios.
On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
wrote:
> Hi Asitha,
>
> Thanks for the explanation.
>
> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
> wrote:
>
>> Hi Eranda,
>>
>>
>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
>> wrote:
>>
>>> Hi all,
>>>
>>> Small addition to the Malintha's suggestion, I think a binding
>>> should be a 3-
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
+1. At the moment we don't have that feature implemented within broker
core. I have created an issue [1] to track this.
[1] https://github.com/wso2/message-broker/issues/142
On Fri, Jan 12, 2018 at 10:02 AM, Hasitha Hiranya wrote:
> Hi Asitha,
>
> We need a API to purge a queue as well.
>
> Thanks
>
> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> Taking all the concerns discussed in to account I did some updates on the
>> design.
>>
>> With this design, I'll be exposing the exchanges, bindings, queues, and
>> consumers. This is to avoid confusion in coming up with a design to expose
>> topics (pub-sub pattern) as a first-class citizen (Since it is another
>> exchange within the broker).
>>
>> Following is the updated design
>>
>>
>> Base path /broker/v.1.0
>>
>>
>>
>>
>>
>>
>>
>> Queues
>>
>>
>> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
>> true, "autoDelete": false }
>> 6 List Queues/Topics GET /queues
>> 7 Get Queue Details GET /queues/{queueName}
>> 8 Delete Queue DELETE /queues/{queueName}
>>
>>
>>
>>
>>
>>
>> Subscriptions for a queue or topic
>>
>>
>> 9 List subscriptions for a destination GET /queues/{queueName}/consumers
>> 10 Get subscriber details GET /queues/{queueName}/consumers/{consumerTag}
>> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>>
>>
>>
>>
>>
>>
>> Exchanges
>>
>>
>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>> "amq.direct", "durable": true }
>> 2 Get All exchanges GET /exchanges
>> 3 Get Exchange GET /exchanges/{exchangeName}
>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>
>>
>>
>>
>>
>>
>> Bindings
>>
>>
>>
>> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>>
>> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
>> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
>> 12345"}
>>
>> Delete binding DELETE /exchanges/{exchangeName}/bind
>> ings/{routingKey}/{queueName}
>>
>>
>>
>>
>>
>>
>> I have few concerns regarding deleting bindings. There is no unique key
>> for the binding hence I was thinking of something like following for the
>> delete binding (combination of routing key and queue name is unique)
>> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>>
>> What about using something like
>> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
>> *for the delete? Can we consider a URI with query params as a unique
>> resource?
>>
>> I have attached the swagger file for the API as well.
>>
>> Regards,
>> Asitha
>>
>>
>> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera
>> wrote:
>>
>>> Hi Asitha,
>>>
>>> I think it is better to say queues rather than destinations since the
>>> actions mean different things in queues and topics. For example,
>>>
>>>- Create
>>> - Queues - we can create the queue in broker core. This will be
>>> useful in assigning permissions
>>> - Topics - We can't do anything at broker code. Corresponding
>>> queues will depend on the subscription id if durable, random name if
>>> non
>>> durable.
>>>- Search
>>>- Queues - we can return queues matching the search criteria
>>> - Topics - It's hard to decide what to return since their can be
>>> unlimited number of options.
>>>- Delete
>>> - Queues - we can delete the specified queues
>>> - Topics - Again bit ambiguous what to delete. Maybe we can go
>>> through the matching bindings and delete the matching queues. My
>>> opinion is
>>> we should not do such a thing.
>>>
>>> Addtionally when we are desiging the REST API better if we dont expose
>>> functionalities that we are expecting to expose through the HTTP transport.
>>> I think the main objective in the first iteration should be to assist the
>>> users in debugging issues. Some information that a user might need is,
>>>
>>>- Queue list
>>>- Subscriptions for a given queue
>>>- Queue details - number messages etc
>>>- Message details
>>>- Permission details
>>>- Binding details of a queue. Will be very useful for topic
>>>scenarios.
>>>
>>>
>>> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
>>> wrote:
>>>
Hi Asitha,
Thanks for the explanation.
On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
wrote:
> Hi Eranda,
>
>
> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
> wrote:
>
>> Hi all,
>>
>> Small addition to the Malintha's suggestion, I think a binding should
>> be a 3-tuple element
>>
> For Bindings, we'll be using queue-name, routing-key, and filters.
> Exchange name can be inferred since we define bindings for a given
> exchange.
>
+1
>
>> Also, is it correct to use the term "destination" to generalize
>> queues and topics? AFAIK it's coming from the JMS world.
>>
> Yes, If we are going w
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Asitha,
We need a API to purge a queue as well.
Thanks
On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara wrote:
> Hi all,
>
> Taking all the concerns discussed in to account I did some updates on the
> design.
>
> With this design, I'll be exposing the exchanges, bindings, queues, and
> consumers. This is to avoid confusion in coming up with a design to expose
> topics (pub-sub pattern) as a first-class citizen (Since it is another
> exchange within the broker).
>
> Following is the updated design
>
>
> Base path /broker/v.1.0
>
>
>
>
>
>
>
> Queues
>
>
> 5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable":
> true, "autoDelete": false }
> 6 List Queues/Topics GET /queues
> 7 Get Queue Details GET /queues/{queueName}
> 8 Delete Queue DELETE /queues/{queueName}
>
>
>
>
>
>
> Subscriptions for a queue or topic
>
>
> 9 List subscriptions for a destination GET /queues/{queueName}/consumers
> 10 Get subscriber details GET /queues/{queueName}/consumers/{consumerTag}
> 11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
>
>
>
>
>
>
> Exchanges
>
>
> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
> "amq.direct", "durable": true }
> 2 Get All exchanges GET /exchanges
> 3 Get Exchange GET /exchanges/{exchangeName}
> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>
>
>
>
>
>
> Bindings
>
>
>
> List bindings for exchange GET /exchanges/{exchangeName}/bindings
>
> Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
> "routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
> 12345"}
>
> Delete binding DELETE /exchanges/{exchangeName}/bindings/{routingKey}/{
> queueName}
>
>
>
>
>
>
> I have few concerns regarding deleting bindings. There is no unique key
> for the binding hence I was thinking of something like following for the
> delete binding (combination of routing key and queue name is unique)
> */exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
>
> What about using something like
> */exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
> *for the delete? Can we consider a URI with query params as a unique
> resource?
>
> I have attached the swagger file for the API as well.
>
> Regards,
> Asitha
>
>
> On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera
> wrote:
>
>> Hi Asitha,
>>
>> I think it is better to say queues rather than destinations since the
>> actions mean different things in queues and topics. For example,
>>
>>- Create
>> - Queues - we can create the queue in broker core. This will be
>> useful in assigning permissions
>> - Topics - We can't do anything at broker code. Corresponding
>> queues will depend on the subscription id if durable, random name if
>> non
>> durable.
>>- Search
>>- Queues - we can return queues matching the search criteria
>> - Topics - It's hard to decide what to return since their can be
>> unlimited number of options.
>>- Delete
>> - Queues - we can delete the specified queues
>> - Topics - Again bit ambiguous what to delete. Maybe we can go
>> through the matching bindings and delete the matching queues. My
>> opinion is
>> we should not do such a thing.
>>
>> Addtionally when we are desiging the REST API better if we dont expose
>> functionalities that we are expecting to expose through the HTTP transport.
>> I think the main objective in the first iteration should be to assist the
>> users in debugging issues. Some information that a user might need is,
>>
>>- Queue list
>>- Subscriptions for a given queue
>>- Queue details - number messages etc
>>- Message details
>>- Permission details
>>- Binding details of a queue. Will be very useful for topic scenarios.
>>
>>
>> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
>> wrote:
>>
>>> Hi Asitha,
>>>
>>> Thanks for the explanation.
>>>
>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
>>> wrote:
>>>
Hi Eranda,
On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
wrote:
> Hi all,
>
> Small addition to the Malintha's suggestion, I think a binding should
> be a 3-tuple element
>
For Bindings, we'll be using queue-name, routing-key, and filters.
Exchange name can be inferred since we define bindings for a given
exchange.
>>> +1
>>>
> Also, is it correct to use the term "destination" to generalize queues
> and topics? AFAIK it's coming from the JMS world.
>
Yes, If we are going with a separate path for queues, outside
/exchanges, we can have something like /queues. Used destinations to avoid
the confusion with queues and topics.
>>> Understood. +1
>>> I think its better to use the term "queue" if we are going to expose
>>> this as a AMQP broker.
>>>
> Thanks,
>
> On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>>
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi all,
Taking all the concerns discussed in to account I did some updates on the
design.
With this design, I'll be exposing the exchanges, bindings, queues, and
consumers. This is to avoid confusion in coming up with a design to expose
topics (pub-sub pattern) as a first-class citizen (Since it is another
exchange within the broker).
Following is the updated design
Base path /broker/v.1.0
Queues
5 Create Queue/Topic POST /queues/ { "name": "queueName", "durable": true,
"autoDelete": false }
6 List Queues/Topics GET /queues
7 Get Queue Details GET /queues/{queueName}
8 Delete Queue DELETE /queues/{queueName}
Subscriptions for a queue or topic
9 List subscriptions for a destination GET /queues/{queueName}/consumers
10 Get subscriber details GET /queues/{queueName}/consumers/{consumerTag}
11 Close subscriber DELETE /queues/{queueName}/consumers/{consumerTag}
Exchanges
1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
"amq.direct", "durable": true }
2 Get All exchanges GET /exchanges
3 Get Exchange GET /exchanges/{exchangeName}
4 Delete Exchange DELETE /exchanges/{exchangeName}
Bindings
List bindings for exchange GET /exchanges/{exchangeName}/bindings
Add binding POST /exchanges/{exchangeName}/bindings {"routingKey":
"routingPattern", "queueName": "myQueue", "filterExpression": "MessageId =
12345"}
Delete binding DELETE
/exchanges/{exchangeName}/bindings/{routingKey}/{queueName}
I have few concerns regarding deleting bindings. There is no unique key for
the binding hence I was thinking of something like following for the delete
binding (combination of routing key and queue name is unique)
*/exchanges/{exchangeName}/bindings/{routingKey}/{queueName}*
What about using something like
*/exchanges/{exchangeName}/bindings?routingKey=myTopic&queueName=tmp_1234
*for the delete? Can we consider a URI with query params as a unique
resource?
I have attached the swagger file for the API as well.
Regards,
Asitha
On Thu, Jan 11, 2018 at 8:36 AM, Asanka Abeyweera wrote:
> Hi Asitha,
>
> I think it is better to say queues rather than destinations since the
> actions mean different things in queues and topics. For example,
>
>- Create
> - Queues - we can create the queue in broker core. This will be
> useful in assigning permissions
> - Topics - We can't do anything at broker code. Corresponding
> queues will depend on the subscription id if durable, random name if non
> durable.
>- Search
>- Queues - we can return queues matching the search criteria
> - Topics - It's hard to decide what to return since their can be
> unlimited number of options.
>- Delete
> - Queues - we can delete the specified queues
> - Topics - Again bit ambiguous what to delete. Maybe we can go
> through the matching bindings and delete the matching queues. My
> opinion is
> we should not do such a thing.
>
> Addtionally when we are desiging the REST API better if we dont expose
> functionalities that we are expecting to expose through the HTTP transport.
> I think the main objective in the first iteration should be to assist the
> users in debugging issues. Some information that a user might need is,
>
>- Queue list
>- Subscriptions for a given queue
>- Queue details - number messages etc
>- Message details
>- Permission details
>- Binding details of a queue. Will be very useful for topic scenarios.
>
>
> On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
> wrote:
>
>> Hi Asitha,
>>
>> Thanks for the explanation.
>>
>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
>> wrote:
>>
>>> Hi Eranda,
>>>
>>>
>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
>>> wrote:
>>>
Hi all,
Small addition to the Malintha's suggestion, I think a binding should
be a 3-tuple element
>>> For Bindings, we'll be using queue-name, routing-key, and filters.
>>> Exchange name can be inferred since we define bindings for a given
>>> exchange.
>>>
>> +1
>>
>>>
Also, is it correct to use the term "destination" to generalize queues
and topics? AFAIK it's coming from the JMS world.
>>> Yes, If we are going with a separate path for queues, outside
>>> /exchanges, we can have something like /queues. Used destinations to avoid
>>> the confusion with queues and topics.
>>>
>> Understood. +1
>> I think its better to use the term "queue" if we are going to expose this
>> as a AMQP broker.
>>
>>>
Thanks,
On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara
wrote:
> Hi all,
>
> @Eranda: Thanks for pointing out the concern. We will be able to get
> over this concern by way of following the approach suggested by Malintha.
>
> @Malintha; Only concern I have with exposing GET /destinations is, we
> will expose all the queues, including temporary queues created for topics.
> Maybe we might be able to get over t
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Asitha,
I think it is better to say queues rather than destinations since the
actions mean different things in queues and topics. For example,
- Create
- Queues - we can create the queue in broker core. This will be
useful in assigning permissions
- Topics - We can't do anything at broker code. Corresponding queues
will depend on the subscription id if durable, random name if non durable.
- Search
- Queues - we can return queues matching the search criteria
- Topics - It's hard to decide what to return since their can be
unlimited number of options.
- Delete
- Queues - we can delete the specified queues
- Topics - Again bit ambiguous what to delete. Maybe we can go
through the matching bindings and delete the matching queues. My
opinion is
we should not do such a thing.
Addtionally when we are desiging the REST API better if we dont expose
functionalities that we are expecting to expose through the HTTP transport.
I think the main objective in the first iteration should be to assist the
users in debugging issues. Some information that a user might need is,
- Queue list
- Subscriptions for a given queue
- Queue details - number messages etc
- Message details
- Permission details
- Binding details of a queue. Will be very useful for topic scenarios.
On Thu, Jan 11, 2018 at 12:41 AM, Eranda Rajapakshe
wrote:
> Hi Asitha,
>
> Thanks for the explanation.
>
> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
> wrote:
>
>> Hi Eranda,
>>
>>
>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
>> wrote:
>>
>>> Hi all,
>>>
>>> Small addition to the Malintha's suggestion, I think a binding should be
>>> a 3-tuple element
>>>
>> For Bindings, we'll be using queue-name, routing-key, and filters.
>> Exchange name can be inferred since we define bindings for a given
>> exchange.
>>
> +1
>
>>
>>> Also, is it correct to use the term "destination" to generalize queues
>>> and topics? AFAIK it's coming from the JMS world.
>>>
>> Yes, If we are going with a separate path for queues, outside /exchanges,
>> we can have something like /queues. Used destinations to avoid the
>> confusion with queues and topics.
>>
> Understood. +1
> I think its better to use the term "queue" if we are going to expose this
> as a AMQP broker.
>
>>
>>> Thanks,
>>>
>>> On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara
>>> wrote:
>>>
Hi all,
@Eranda: Thanks for pointing out the concern. We will be able to get
over this concern by way of following the approach suggested by Malintha.
@Malintha; Only concern I have with exposing GET /destinations is, we
will expose all the queues, including temporary queues created for topics.
Maybe we might be able to get over this by way of using filters.
@Sanjeewa: We are planning to write this admin service using MSF4J and
we are exposing this to do administrative tasks on the broker. Eventually
the broker UI will use these servises as well. I will work on creating the
swagger definitions based on these suggessions.
Regards,
Asitha
On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe <
malint...@wso2.com> wrote:
> Hi all,
>
> A suggestion for Eranda's concern, for that I think we need to remove
> the "exchanges" from the destinations APIs.
>
> One possible solution is:
>
> *Create Queue/Topic*
> POST /destinations { "name": "queueName", "durable": true,
> "autoDelete": false }
>
> *List Queues/Topics *
> GET /destinations
>
> *Get Queue Details *
> GET /destinations/{destinationName}
>
> *Delete Queue *
> DELETE /destinations/{destinationName}
>
> *New APIs for adding/retrieving bindings:*
>
> *Add a new binding: (not sure about the name "binding" is appropriate)*
> POST /bindings
> {
> "exchangeName" : "exchange1",
> "destinationName" : "destination1"
> }
>
> *Get bindings for a particular exchange:*
> GET /bindings?exchangeName="exchange1" => Provides a list of bindings
> for the particular exchange
>
> During a discussion, Asitha mentioned about default exchange; If
> exchangeName is not provided can we use it as its default value?
>
> WDYT?
>
> Thanks!
>
>
> On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda > wrote:
>
>>
>>
>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara
>> wrote:
>>
>>> Adding Harshak, Sanjeewa and Malinthaa
>>>
>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara >> > wrote:
>>>
Hi all,
In the new message broker implementation we are implementing broker
semantics based on AMQP 0.9.1 specification.
From an administrative operations perspective, we have identified
following resources to be ex
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Asitha,
Thanks for the explanation.
On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara
wrote:
> Hi Eranda,
>
>
> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe
> wrote:
>
>> Hi all,
>>
>> Small addition to the Malintha's suggestion, I think a binding should be
>> a 3-tuple element
>>
> For Bindings, we'll be using queue-name, routing-key, and filters.
> Exchange name can be inferred since we define bindings for a given
> exchange.
>
+1
>
>> Also, is it correct to use the term "destination" to generalize queues
>> and topics? AFAIK it's coming from the JMS world.
>>
> Yes, If we are going with a separate path for queues, outside /exchanges,
> we can have something like /queues. Used destinations to avoid the
> confusion with queues and topics.
>
Understood. +1
I think its better to use the term "queue" if we are going to expose this
as a AMQP broker.
>
>> Thanks,
>>
>> On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara
>> wrote:
>>
>>> Hi all,
>>>
>>> @Eranda: Thanks for pointing out the concern. We will be able to get
>>> over this concern by way of following the approach suggested by Malintha.
>>>
>>> @Malintha; Only concern I have with exposing GET /destinations is, we
>>> will expose all the queues, including temporary queues created for topics.
>>> Maybe we might be able to get over this by way of using filters.
>>>
>>> @Sanjeewa: We are planning to write this admin service using MSF4J and
>>> we are exposing this to do administrative tasks on the broker. Eventually
>>> the broker UI will use these servises as well. I will work on creating the
>>> swagger definitions based on these suggessions.
>>>
>>> Regards,
>>> Asitha
>>>
>>> On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe <
>>> malint...@wso2.com> wrote:
>>>
Hi all,
A suggestion for Eranda's concern, for that I think we need to remove
the "exchanges" from the destinations APIs.
One possible solution is:
*Create Queue/Topic*
POST /destinations { "name": "queueName", "durable": true,
"autoDelete": false }
*List Queues/Topics *
GET /destinations
*Get Queue Details *
GET /destinations/{destinationName}
*Delete Queue *
DELETE /destinations/{destinationName}
*New APIs for adding/retrieving bindings:*
*Add a new binding: (not sure about the name "binding" is appropriate)*
POST /bindings
{
"exchangeName" : "exchange1",
"destinationName" : "destination1"
}
*Get bindings for a particular exchange:*
GET /bindings?exchangeName="exchange1" => Provides a list of bindings
for the particular exchange
During a discussion, Asitha mentioned about default exchange; If
exchangeName is not provided can we use it as its default value?
WDYT?
Thanks!
On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda
wrote:
>
>
> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara
> wrote:
>
>> Adding Harshak, Sanjeewa and Malinthaa
>>
>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
>> wrote:
>>
>>> Hi all,
>>>
>>> In the new message broker implementation we are implementing broker
>>> semantics based on AMQP 0.9.1 specification.
>>>
>>> From an administrative operations perspective, we have identified
>>> following resources to be exposed through restful web services.
>>>
>>>- exchanges
>>>- queues
>>>- topics
>>>- consumers
>>>
>>> There are currently two types of exchange. Namely,
>>>
>>>- direct exchange - relates to mostly known queue scenarios
>>>- topic exchange - relates to topic scenarios (pub-sub pattern)
>>>
>>>
>>> *Queues and topics*
>>>
>>> Within the broker, there are only queues. These queues are bound to
>>> direct and topic exchanges. Depending on the bound exchange we perceive
>>> them as either pub-sub pattern or queue pattern.
>>> Therefore within the Admin API's we refer to either a queue or a
>>> topic as a *destination.*
>>>
>>>
>>> *Consumers*
>>>
>>> For each internal queue (a destination) there will be consumers.
>>> Messages are delivered to consumers in round robin manner.
>>>
>>> In topic scenario (pub-sub pattern) topic exchange will bind a
>>> separate queue (a destination) per each consumer with the same topic
>>> name.
>>> When a message is published it will get delivered to the set of queues
>>> with
>>> the matching topic and then to the relevant consumers on those queues
>>>
>>> Considering the above broker semantics we have come up with the
>>> following Admin API design for the broker
>>>
>>>
>>> Base path /broker/v.1.0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Exchanges*
>>> *Method*
>>> *Path*
>>> *Payload*
>>
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Eranda,
On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe wrote:
> Hi all,
>
> Small addition to the Malintha's suggestion, I think a binding should be a
> 3-tuple element
>
For Bindings, we'll be using queue-name, routing-key, and filters. Exchange
name can be inferred since we define bindings for a given exchange.
>
> Also, is it correct to use the term "destination" to generalize queues and
> topics? AFAIK it's coming from the JMS world.
>
Yes, If we are going with a separate path for queues, outside /exchanges,
we can have something like /queues. Used destinations to avoid the
confusion with queues and topics.
>
> Thanks,
>
> On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> @Eranda: Thanks for pointing out the concern. We will be able to get over
>> this concern by way of following the approach suggested by Malintha.
>>
>> @Malintha; Only concern I have with exposing GET /destinations is, we
>> will expose all the queues, including temporary queues created for topics.
>> Maybe we might be able to get over this by way of using filters.
>>
>> @Sanjeewa: We are planning to write this admin service using MSF4J and we
>> are exposing this to do administrative tasks on the broker. Eventually the
>> broker UI will use these servises as well. I will work on creating the
>> swagger definitions based on these suggessions.
>>
>> Regards,
>> Asitha
>>
>> On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe > > wrote:
>>
>>> Hi all,
>>>
>>> A suggestion for Eranda's concern, for that I think we need to remove
>>> the "exchanges" from the destinations APIs.
>>>
>>> One possible solution is:
>>>
>>> *Create Queue/Topic*
>>> POST /destinations { "name": "queueName", "durable": true,
>>> "autoDelete": false }
>>>
>>> *List Queues/Topics *
>>> GET /destinations
>>>
>>> *Get Queue Details *
>>> GET /destinations/{destinationName}
>>>
>>> *Delete Queue *
>>> DELETE /destinations/{destinationName}
>>>
>>> *New APIs for adding/retrieving bindings:*
>>>
>>> *Add a new binding: (not sure about the name "binding" is appropriate)*
>>> POST /bindings
>>> {
>>> "exchangeName" : "exchange1",
>>> "destinationName" : "destination1"
>>> }
>>>
>>> *Get bindings for a particular exchange:*
>>> GET /bindings?exchangeName="exchange1" => Provides a list of bindings
>>> for the particular exchange
>>>
>>> During a discussion, Asitha mentioned about default exchange; If
>>> exchangeName is not provided can we use it as its default value?
>>>
>>> WDYT?
>>>
>>> Thanks!
>>>
>>>
>>> On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda
>>> wrote:
>>>
On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara
wrote:
> Adding Harshak, Sanjeewa and Malinthaa
>
> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> In the new message broker implementation we are implementing broker
>> semantics based on AMQP 0.9.1 specification.
>>
>> From an administrative operations perspective, we have identified
>> following resources to be exposed through restful web services.
>>
>>- exchanges
>>- queues
>>- topics
>>- consumers
>>
>> There are currently two types of exchange. Namely,
>>
>>- direct exchange - relates to mostly known queue scenarios
>>- topic exchange - relates to topic scenarios (pub-sub pattern)
>>
>>
>> *Queues and topics*
>>
>> Within the broker, there are only queues. These queues are bound to
>> direct and topic exchanges. Depending on the bound exchange we perceive
>> them as either pub-sub pattern or queue pattern.
>> Therefore within the Admin API's we refer to either a queue or a
>> topic as a *destination.*
>>
>>
>> *Consumers*
>>
>> For each internal queue (a destination) there will be consumers.
>> Messages are delivered to consumers in round robin manner.
>>
>> In topic scenario (pub-sub pattern) topic exchange will bind a
>> separate queue (a destination) per each consumer with the same topic
>> name.
>> When a message is published it will get delivered to the set of queues
>> with
>> the matching topic and then to the relevant consumers on those queues
>>
>> Considering the above broker semantics we have come up with the
>> following Admin API design for the broker
>>
>>
>> Base path /broker/v.1.0
>>
>>
>>
>>
>>
>>
>>
>> *Exchanges*
>> *Method*
>> *Path*
>> *Payload*
>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>> "amq.direct", "durable": true }
>> 2 Get All exchanges GET /exchanges
>> 3 Get Exchange GET /exchanges/{exchangeName}
>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>
>>
>>
>>
>>
>>
>> *Destinations (Queues/Topics)*
>>
>>
>> 5 Create Queue/Topic POST /exchanges/{exc
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi all,
Small addition to the Malintha's suggestion, I think a binding should be a
3-tuple element
Also, is it correct to use the term "destination" to generalize queues and
topics? AFAIK it's coming from the JMS world.
Thanks,
On Wed, Jan 10, 2018 at 6:29 PM, Asitha Nanayakkara wrote:
> Hi all,
>
> @Eranda: Thanks for pointing out the concern. We will be able to get over
> this concern by way of following the approach suggested by Malintha.
>
> @Malintha; Only concern I have with exposing GET /destinations is, we will
> expose all the queues, including temporary queues created for topics. Maybe
> we might be able to get over this by way of using filters.
>
> @Sanjeewa: We are planning to write this admin service using MSF4J and we
> are exposing this to do administrative tasks on the broker. Eventually the
> broker UI will use these servises as well. I will work on creating the
> swagger definitions based on these suggessions.
>
> Regards,
> Asitha
>
> On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe
> wrote:
>
>> Hi all,
>>
>> A suggestion for Eranda's concern, for that I think we need to remove the
>> "exchanges" from the destinations APIs.
>>
>> One possible solution is:
>>
>> *Create Queue/Topic*
>> POST /destinations { "name": "queueName", "durable": true, "autoDelete":
>> false }
>>
>> *List Queues/Topics *
>> GET /destinations
>>
>> *Get Queue Details *
>> GET /destinations/{destinationName}
>>
>> *Delete Queue *
>> DELETE /destinations/{destinationName}
>>
>> *New APIs for adding/retrieving bindings:*
>>
>> *Add a new binding: (not sure about the name "binding" is appropriate)*
>> POST /bindings
>> {
>> "exchangeName" : "exchange1",
>> "destinationName" : "destination1"
>> }
>>
>> *Get bindings for a particular exchange:*
>> GET /bindings?exchangeName="exchange1" => Provides a list of bindings
>> for the particular exchange
>>
>> During a discussion, Asitha mentioned about default exchange; If
>> exchangeName is not provided can we use it as its default value?
>>
>> WDYT?
>>
>> Thanks!
>>
>>
>> On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara
>>> wrote:
>>>
Adding Harshak, Sanjeewa and Malinthaa
On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
wrote:
> Hi all,
>
> In the new message broker implementation we are implementing broker
> semantics based on AMQP 0.9.1 specification.
>
> From an administrative operations perspective, we have identified
> following resources to be exposed through restful web services.
>
>- exchanges
>- queues
>- topics
>- consumers
>
> There are currently two types of exchange. Namely,
>
>- direct exchange - relates to mostly known queue scenarios
>- topic exchange - relates to topic scenarios (pub-sub pattern)
>
>
> *Queues and topics*
>
> Within the broker, there are only queues. These queues are bound to
> direct and topic exchanges. Depending on the bound exchange we perceive
> them as either pub-sub pattern or queue pattern.
> Therefore within the Admin API's we refer to either a queue or a topic
> as a *destination.*
>
>
> *Consumers*
>
> For each internal queue (a destination) there will be consumers.
> Messages are delivered to consumers in round robin manner.
>
> In topic scenario (pub-sub pattern) topic exchange will bind a
> separate queue (a destination) per each consumer with the same topic name.
> When a message is published it will get delivered to the set of queues
> with
> the matching topic and then to the relevant consumers on those queues
>
> Considering the above broker semantics we have come up with the
> following Admin API design for the broker
>
>
> Base path /broker/v.1.0
>
>
>
>
>
>
>
> *Exchanges*
> *Method*
> *Path*
> *Payload*
> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
> "amq.direct", "durable": true }
> 2 Get All exchanges GET /exchanges
> 3 Get Exchange GET /exchanges/{exchangeName}
> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>
>
>
>
>
>
> *Destinations (Queues/Topics)*
>
>
> 5 Create Queue/Topic POST /exchanges/{exchangeName}/destinations {
> "name": "queueName", "durable": true, "autoDelete": false }
> 6 List Queues/Topics GET /exchanges/{exchangeName}/destinations
> 7 Get Queue Details GET /exchanges/{exchangeName}/dest
> inations/{destinationName}
> 8 Delete Queue DELETE /exchanges/{exchangeName}/dest
> inations/{destinationName}
>
>
>
>
>
>
> *Consumers (for a queue or topic)*
>
>
> 9 List subscriptions for a destination GET
> /exchanges/{exchangeName}/destinations/{destinationName}/consumers
> 10 Get
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi all,
@Eranda: Thanks for pointing out the concern. We will be able to get over
this concern by way of following the approach suggested by Malintha.
@Malintha; Only concern I have with exposing GET /destinations is, we will
expose all the queues, including temporary queues created for topics. Maybe
we might be able to get over this by way of using filters.
@Sanjeewa: We are planning to write this admin service using MSF4J and we
are exposing this to do administrative tasks on the broker. Eventually the
broker UI will use these servises as well. I will work on creating the
swagger definitions based on these suggessions.
Regards,
Asitha
On Wed, Jan 10, 2018 at 6:10 PM, Malintha Amarasinghe
wrote:
> Hi all,
>
> A suggestion for Eranda's concern, for that I think we need to remove the
> "exchanges" from the destinations APIs.
>
> One possible solution is:
>
> *Create Queue/Topic*
> POST /destinations { "name": "queueName", "durable": true, "autoDelete":
> false }
>
> *List Queues/Topics *
> GET /destinations
>
> *Get Queue Details *
> GET /destinations/{destinationName}
>
> *Delete Queue *
> DELETE /destinations/{destinationName}
>
> *New APIs for adding/retrieving bindings:*
>
> *Add a new binding: (not sure about the name "binding" is appropriate)*
> POST /bindings
> {
> "exchangeName" : "exchange1",
> "destinationName" : "destination1"
> }
>
> *Get bindings for a particular exchange:*
> GET /bindings?exchangeName="exchange1" => Provides a list of bindings for
> the particular exchange
>
> During a discussion, Asitha mentioned about default exchange; If
> exchangeName is not provided can we use it as its default value?
>
> WDYT?
>
> Thanks!
>
>
> On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda
> wrote:
>
>>
>>
>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara
>> wrote:
>>
>>> Adding Harshak, Sanjeewa and Malinthaa
>>>
>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
>>> wrote:
>>>
Hi all,
In the new message broker implementation we are implementing broker
semantics based on AMQP 0.9.1 specification.
From an administrative operations perspective, we have identified
following resources to be exposed through restful web services.
- exchanges
- queues
- topics
- consumers
There are currently two types of exchange. Namely,
- direct exchange - relates to mostly known queue scenarios
- topic exchange - relates to topic scenarios (pub-sub pattern)
*Queues and topics*
Within the broker, there are only queues. These queues are bound to
direct and topic exchanges. Depending on the bound exchange we perceive
them as either pub-sub pattern or queue pattern.
Therefore within the Admin API's we refer to either a queue or a topic
as a *destination.*
*Consumers*
For each internal queue (a destination) there will be consumers.
Messages are delivered to consumers in round robin manner.
In topic scenario (pub-sub pattern) topic exchange will bind a separate
queue (a destination) per each consumer with the same topic name. When a
message is published it will get delivered to the set of queues with the
matching topic and then to the relevant consumers on those queues
Considering the above broker semantics we have come up with the
following Admin API design for the broker
Base path /broker/v.1.0
*Exchanges*
*Method*
*Path*
*Payload*
1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
"amq.direct", "durable": true }
2 Get All exchanges GET /exchanges
3 Get Exchange GET /exchanges/{exchangeName}
4 Delete Exchange DELETE /exchanges/{exchangeName}
*Destinations (Queues/Topics)*
5 Create Queue/Topic POST /exchanges/{exchangeName}/destinations {
"name": "queueName", "durable": true, "autoDelete": false }
6 List Queues/Topics GET /exchanges/{exchangeName}/destinations
7 Get Queue Details GET /exchanges/{exchangeName}/dest
inations/{destinationName}
8 Delete Queue DELETE /exchanges/{exchangeName}/dest
inations/{destinationName}
*Consumers (for a queue or topic)*
9 List subscriptions for a destination GET
/exchanges/{exchangeName}/destinations/{destinationName}/consumers
10 Get subscriber details GET /exchanges/{exchangeName}/dest
inations/{destinationName}/consumers/{consumerTag}
11 Close subscriber DELETE /exchanges/{exchangeName}/dest
inations/{destinationName}/consumers/{consumerTag}
When retrieving a set of exchanges, destinations or consumers we will
be able to filter the result set by way of using query parameters.
>>> This API looks good and followed REST nature. I assume excha
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi all,
A suggestion for Eranda's concern, for that I think we need to remove the
"exchanges" from the destinations APIs.
One possible solution is:
*Create Queue/Topic*
POST /destinations { "name": "queueName", "durable": true, "autoDelete":
false }
*List Queues/Topics *
GET /destinations
*Get Queue Details *
GET /destinations/{destinationName}
*Delete Queue *
DELETE /destinations/{destinationName}
*New APIs for adding/retrieving bindings:*
*Add a new binding: (not sure about the name "binding" is appropriate)*
POST /bindings
{
"exchangeName" : "exchange1",
"destinationName" : "destination1"
}
*Get bindings for a particular exchange:*
GET /bindings?exchangeName="exchange1" => Provides a list of bindings for
the particular exchange
During a discussion, Asitha mentioned about default exchange; If
exchangeName is not provided can we use it as its default value?
WDYT?
Thanks!
On Wed, Jan 10, 2018 at 5:59 PM, Sanjeewa Malalgoda
wrote:
>
>
> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara
> wrote:
>
>> Adding Harshak, Sanjeewa and Malinthaa
>>
>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
>> wrote:
>>
>>> Hi all,
>>>
>>> In the new message broker implementation we are implementing broker
>>> semantics based on AMQP 0.9.1 specification.
>>>
>>> From an administrative operations perspective, we have identified
>>> following resources to be exposed through restful web services.
>>>
>>>- exchanges
>>>- queues
>>>- topics
>>>- consumers
>>>
>>> There are currently two types of exchange. Namely,
>>>
>>>- direct exchange - relates to mostly known queue scenarios
>>>- topic exchange - relates to topic scenarios (pub-sub pattern)
>>>
>>>
>>> *Queues and topics*
>>>
>>> Within the broker, there are only queues. These queues are bound to
>>> direct and topic exchanges. Depending on the bound exchange we perceive
>>> them as either pub-sub pattern or queue pattern.
>>> Therefore within the Admin API's we refer to either a queue or a topic
>>> as a *destination.*
>>>
>>>
>>> *Consumers*
>>>
>>> For each internal queue (a destination) there will be consumers.
>>> Messages are delivered to consumers in round robin manner.
>>>
>>> In topic scenario (pub-sub pattern) topic exchange will bind a separate
>>> queue (a destination) per each consumer with the same topic name. When a
>>> message is published it will get delivered to the set of queues with the
>>> matching topic and then to the relevant consumers on those queues
>>>
>>> Considering the above broker semantics we have come up with the
>>> following Admin API design for the broker
>>>
>>>
>>> Base path /broker/v.1.0
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Exchanges*
>>> *Method*
>>> *Path*
>>> *Payload*
>>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>>> "amq.direct", "durable": true }
>>> 2 Get All exchanges GET /exchanges
>>> 3 Get Exchange GET /exchanges/{exchangeName}
>>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Destinations (Queues/Topics)*
>>>
>>>
>>> 5 Create Queue/Topic POST /exchanges/{exchangeName}/destinations {
>>> "name": "queueName", "durable": true, "autoDelete": false }
>>> 6 List Queues/Topics GET /exchanges/{exchangeName}/destinations
>>> 7 Get Queue Details GET /exchanges/{exchangeName}/dest
>>> inations/{destinationName}
>>> 8 Delete Queue DELETE /exchanges/{exchangeName}/dest
>>> inations/{destinationName}
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Consumers (for a queue or topic)*
>>>
>>>
>>> 9 List subscriptions for a destination GET
>>> /exchanges/{exchangeName}/destinations/{destinationName}/consumers
>>> 10 Get subscriber details GET /exchanges/{exchangeName}/dest
>>> inations/{destinationName}/consumers/{consumerTag}
>>> 11 Close subscriber DELETE /exchanges/{exchangeName}/dest
>>> inations/{destinationName}/consumers/{consumerTag}
>>>
>>>
>>>
>>>
>>>
>>>
>>> When retrieving a set of exchanges, destinations or consumers we will be
>>> able to filter the result set by way of using query parameters.
>>>
>> This API looks good and followed REST nature. I assume exchange name,
> destination name, consumer tag etc are unique. Then only we can build above
> mentioned resource model.
> Also do we need to let users to check the possibility of creating
> exchange, destination or consumer tag before we create it. Then we might
> need http head method as well.
> If you need to update que details then you have to use put as well. Ex:
> enable/disable auto delete after we create it first time.
> Also lets define proper response codes as well(201 to created, 202
> accepted etc).
>
> What is the plan to expose this API to outside? Is it MSF4J? If that is
> the case you can start with swagger definition and move forward.
>
> Thanks,
> sanjeewa.
>
>
>>> Regards,
>>> Asitha
>>>
>>> --
>>> *Asitha Nanayakkara*
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara wrote:
> Adding Harshak, Sanjeewa and Malinthaa
>
> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> In the new message broker implementation we are implementing broker
>> semantics based on AMQP 0.9.1 specification.
>>
>> From an administrative operations perspective, we have identified
>> following resources to be exposed through restful web services.
>>
>>- exchanges
>>- queues
>>- topics
>>- consumers
>>
>> There are currently two types of exchange. Namely,
>>
>>- direct exchange - relates to mostly known queue scenarios
>>- topic exchange - relates to topic scenarios (pub-sub pattern)
>>
>>
>> *Queues and topics*
>>
>> Within the broker, there are only queues. These queues are bound to
>> direct and topic exchanges. Depending on the bound exchange we perceive
>> them as either pub-sub pattern or queue pattern.
>> Therefore within the Admin API's we refer to either a queue or a topic as
>> a *destination.*
>>
>>
>> *Consumers*
>>
>> For each internal queue (a destination) there will be consumers. Messages
>> are delivered to consumers in round robin manner.
>>
>> In topic scenario (pub-sub pattern) topic exchange will bind a separate
>> queue (a destination) per each consumer with the same topic name. When a
>> message is published it will get delivered to the set of queues with the
>> matching topic and then to the relevant consumers on those queues
>>
>> Considering the above broker semantics we have come up with the following
>> Admin API design for the broker
>>
>>
>> Base path /broker/v.1.0
>>
>>
>>
>>
>>
>>
>>
>> *Exchanges*
>> *Method*
>> *Path*
>> *Payload*
>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>> "amq.direct", "durable": true }
>> 2 Get All exchanges GET /exchanges
>> 3 Get Exchange GET /exchanges/{exchangeName}
>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>
>>
>>
>>
>>
>>
>> *Destinations (Queues/Topics)*
>>
>>
>> 5 Create Queue/Topic POST /exchanges/{exchangeName}/destinations {
>> "name": "queueName", "durable": true, "autoDelete": false }
>> 6 List Queues/Topics GET /exchanges/{exchangeName}/destinations
>> 7 Get Queue Details GET /exchanges/{exchangeName}/dest
>> inations/{destinationName}
>> 8 Delete Queue DELETE /exchanges/{exchangeName}/dest
>> inations/{destinationName}
>>
>>
>>
>>
>>
>>
>> *Consumers (for a queue or topic)*
>>
>>
>> 9 List subscriptions for a destination GET /exchanges/{exchangeName}/dest
>> inations/{destinationName}/consumers
>> 10 Get subscriber details GET /exchanges/{exchangeName}/dest
>> inations/{destinationName}/consumers/{consumerTag}
>> 11 Close subscriber DELETE /exchanges/{exchangeName}/dest
>> inations/{destinationName}/consumers/{consumerTag}
>>
>>
>>
>>
>>
>>
>> When retrieving a set of exchanges, destinations or consumers we will be
>> able to filter the result set by way of using query parameters.
>>
> This API looks good and followed REST nature. I assume exchange name,
destination name, consumer tag etc are unique. Then only we can build above
mentioned resource model.
Also do we need to let users to check the possibility of creating exchange,
destination or consumer tag before we create it. Then we might need http
head method as well.
If you need to update que details then you have to use put as well. Ex:
enable/disable auto delete after we create it first time.
Also lets define proper response codes as well(201 to created, 202 accepted
etc).
What is the plan to expose this API to outside? Is it MSF4J? If that is the
case you can start with swagger definition and move forward.
Thanks,
sanjeewa.
>> Regards,
>> Asitha
>>
>> --
>> *Asitha Nanayakkara*
>>
>>
>
>
> --
> *Asitha Nanayakkara*
>
>
--
*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Hi Asitha,
Won't there be situations where we need to bind a queue with more than one
exchange? If so, is it possible to handle such scenario using the proposed
API?
Thanks,
On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara wrote:
> Adding Harshak, Sanjeewa and Malinthaa
>
> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara
> wrote:
>
>> Hi all,
>>
>> In the new message broker implementation we are implementing broker
>> semantics based on AMQP 0.9.1 specification.
>>
>> From an administrative operations perspective, we have identified
>> following resources to be exposed through restful web services.
>>
>>- exchanges
>>- queues
>>- topics
>>- consumers
>>
>> There are currently two types of exchange. Namely,
>>
>>- direct exchange - relates to mostly known queue scenarios
>>- topic exchange - relates to topic scenarios (pub-sub pattern)
>>
>>
>> *Queues and topics*
>>
>> Within the broker, there are only queues. These queues are bound to
>> direct and topic exchanges. Depending on the bound exchange we perceive
>> them as either pub-sub pattern or queue pattern.
>> Therefore within the Admin API's we refer to either a queue or a topic as
>> a *destination.*
>>
>>
>> *Consumers*
>>
>> For each internal queue (a destination) there will be consumers. Messages
>> are delivered to consumers in round robin manner.
>>
>> In topic scenario (pub-sub pattern) topic exchange will bind a separate
>> queue (a destination) per each consumer with the same topic name. When a
>> message is published it will get delivered to the set of queues with the
>> matching topic and then to the relevant consumers on those queues
>>
>> Considering the above broker semantics we have come up with the following
>> Admin API design for the broker
>>
>>
>> Base path /broker/v.1.0
>>
>>
>>
>>
>>
>>
>>
>> *Exchanges*
>> *Method*
>> *Path*
>> *Payload*
>> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
>> "amq.direct", "durable": true }
>> 2 Get All exchanges GET /exchanges
>> 3 Get Exchange GET /exchanges/{exchangeName}
>> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>>
>>
>>
>>
>>
>>
>> *Destinations (Queues/Topics)*
>>
>>
>> 5 Create Queue/Topic POST /exchanges/{exchangeName}/destinations {
>> "name": "queueName", "durable": true, "autoDelete": false }
>> 6 List Queues/Topics GET /exchanges/{exchangeName}/destinations
>> 7 Get Queue Details GET /exchanges/{exchangeName}/dest
>> inations/{destinationName}
>> 8 Delete Queue DELETE /exchanges/{exchangeName}/dest
>> inations/{destinationName}
>>
>>
>>
>>
>>
>>
>> *Consumers (for a queue or topic)*
>>
>>
>> 9 List subscriptions for a destination GET /exchanges/{exchangeName}/dest
>> inations/{destinationName}/consumers
>> 10 Get subscriber details GET /exchanges/{exchangeName}/dest
>> inations/{destinationName}/consumers/{consumerTag}
>> 11 Close subscriber DELETE /exchanges/{exchangeName}/dest
>> inations/{destinationName}/consumers/{consumerTag}
>>
>>
>>
>>
>>
>>
>> When retrieving a set of exchanges, destinations or consumers we will be
>> able to filter the result set by way of using query parameters.
>>
>> Regards,
>> Asitha
>>
>> --
>> *Asitha Nanayakkara*
>>
>>
>
>
> --
> *Asitha Nanayakkara*
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*Eranda Rajapakshe*
Software Engineer
WSO2 Inc.
Mobile : +94784822608
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [MB4] Restful Admin API's for Message Broker
Adding Harshak, Sanjeewa and Malinthaa
On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara wrote:
> Hi all,
>
> In the new message broker implementation we are implementing broker
> semantics based on AMQP 0.9.1 specification.
>
> From an administrative operations perspective, we have identified
> following resources to be exposed through restful web services.
>
>- exchanges
>- queues
>- topics
>- consumers
>
> There are currently two types of exchange. Namely,
>
>- direct exchange - relates to mostly known queue scenarios
>- topic exchange - relates to topic scenarios (pub-sub pattern)
>
>
> *Queues and topics*
>
> Within the broker, there are only queues. These queues are bound to direct
> and topic exchanges. Depending on the bound exchange we perceive them as
> either pub-sub pattern or queue pattern.
> Therefore within the Admin API's we refer to either a queue or a topic as
> a *destination.*
>
>
> *Consumers*
>
> For each internal queue (a destination) there will be consumers. Messages
> are delivered to consumers in round robin manner.
>
> In topic scenario (pub-sub pattern) topic exchange will bind a separate
> queue (a destination) per each consumer with the same topic name. When a
> message is published it will get delivered to the set of queues with the
> matching topic and then to the relevant consumers on those queues
>
> Considering the above broker semantics we have come up with the following
> Admin API design for the broker
>
>
> Base path /broker/v.1.0
>
>
>
>
>
>
>
> *Exchanges*
> *Method*
> *Path*
> *Payload*
> 1 Create Exchange POST /exchanges { "name": "exchangeName", "type":
> "amq.direct", "durable": true }
> 2 Get All exchanges GET /exchanges
> 3 Get Exchange GET /exchanges/{exchangeName}
> 4 Delete Exchange DELETE /exchanges/{exchangeName}
>
>
>
>
>
>
> *Destinations (Queues/Topics)*
>
>
> 5 Create Queue/Topic POST /exchanges/{exchangeName}/destinations {
> "name": "queueName", "durable": true, "autoDelete": false }
> 6 List Queues/Topics GET /exchanges/{exchangeName}/destinations
> 7 Get Queue Details GET /exchanges/{exchangeName}/
> destinations/{destinationName}
> 8 Delete Queue DELETE /exchanges/{exchangeName}/
> destinations/{destinationName}
>
>
>
>
>
>
> *Consumers (for a queue or topic)*
>
>
> 9 List subscriptions for a destination GET /exchanges/{exchangeName}/
> destinations/{destinationName}/consumers
> 10 Get subscriber details GET /exchanges/{exchangeName}/
> destinations/{destinationName}/consumers/{consumerTag}
> 11 Close subscriber DELETE /exchanges/{exchangeName}/
> destinations/{destinationName}/consumers/{consumerTag}
>
>
>
>
>
>
> When retrieving a set of exchanges, destinations or consumers we will be
> able to filter the result set by way of using query parameters.
>
> Regards,
> Asitha
>
> --
> *Asitha Nanayakkara*
>
>
--
*Asitha Nanayakkara*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
