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 <[email protected]>
wrote:
> +1. That looks good.
>
> Thanks,
> sanjeewa.
>
> On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <
>>>> [email protected]> 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
>>>>> <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
>>>>> <https://localhost:9292/admin/1.0>*/exchanges/*exchange1*/bindings/
>>>>> *4a349d47-12fa-490c-bb06-d90610a4897d*
>>>>> DELETE *https://localhost:9292/admin/1.0
>>>>> <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 <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara <[email protected]>
>>>>>> 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 <[email protected]
>>>>>>> > 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 <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Asitha,
>>>>>>>>>
>>>>>>>>> Thanks for the explanation.
>>>>>>>>>
>>>>>>>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Eranda,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Small addition to the Malintha's suggestion, I think a binding
>>>>>>>>>>> should be a 3-tuple element <exchange-name, queue-name, routing-key>
>>>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>> [email protected]> 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 <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara <
>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Adding Harshak, Sanjeewa and Malinthaa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara <
>>>>>>>>>>>>>>> [email protected]> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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* <http://asitha.github.io/>
>>>>>>>>>>>>>>>> Associate Technical Lead
>>>>>>>>>>>>>>>> WSO2, Inc. <http://wso2.com/>
>>>>>>>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682>
>>>>>>>>>>>>>>>> [image: https://wso2.com/signature]
>>>>>>>>>>>>>>>> <https://wso2.com/signature>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/>
>>>>>>>>>>>>>>> Associate Technical Lead
>>>>>>>>>>>>>>> WSO2, Inc. <http://wso2.com/>
>>>>>>>>>>>>>>> Mob: +94 77 853 0682 <077%20853%200682>
>>>>>>>>>>>>>>> [image: https://wso2.com/signature]
>>>>>>>>>>>>>>> <https://wso2.com/signature>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>>>>>>> WSO2 Inc.
>>>>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Malintha Amarasinghe
>>>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>>>>>>>> http://wso2.com/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/>
>>>>>>>>>>>> Associate Technical Lead
>>>>>>>>>>>> WSO2, Inc. <http://wso2.com/>
>>>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682>
>>>>>>>>>>>> [image: https://wso2.com/signature]
>>>>>>>>>>>> <https://wso2.com/signature>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Eranda Rajapakshe*
>>>>>>>>>>> Software Engineer
>>>>>>>>>>> WSO2 Inc.
>>>>>>>>>>> Mobile : +94784822608
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/>
>>>>>>>>>> Associate Technical Lead
>>>>>>>>>> WSO2, Inc. <http://wso2.com/>
>>>>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682>
>>>>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Eranda Rajapakshe*
>>>>>>>>> Software Engineer
>>>>>>>>> WSO2 Inc.
>>>>>>>>> Mobile : +94784822608
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Architecture mailing list
>>>>>>>>> [email protected]
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Asanka Abeyweera
>>>>>>>> Associate Technical Lead
>>>>>>>> WSO2 Inc.
>>>>>>>>
>>>>>>>> Phone: +94 712228648 <+94%2071%20222%208648>
>>>>>>>> Blog: a5anka.github.io
>>>>>>>>
>>>>>>>> <https://wso2.com/signature>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Asitha Nanayakkara* <http://asitha.github.io/>
>>>>>>> Associate Technical Lead
>>>>>>> WSO2, Inc. <http://wso2.com/>
>>>>>>> Mob: +94 77 853 0682 <+94%2077%20853%200682>
>>>>>>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Architecture mailing list
>>>>>>> [email protected]
>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Harsha Kumara
>>>>>> Software Engineer, WSO2 Inc.
>>>>>> Mobile: +94775505618 <+94%2077%20550%205618>
>>>>>> Blog:harshcreationz.blogspot.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Architecture mailing list
>>>>>> [email protected]
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Malintha Amarasinghe
>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>> http://wso2.com/
>>>>>
>>>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Asanka Abeyweera
>>>> Associate Technical Lead
>>>> WSO2 Inc.
>>>>
>>>> Phone: +94 712228648 <071%20222%208648>
>>>> Blog: a5anka.github.io
>>>>
>>>> <https://wso2.com/signature>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779 <+94%2071%20306%208779>
>>>
>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>
>>>
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Asanka Abeyweera
>> Associate Technical Lead
>> WSO2 Inc.
>>
>> Phone: +94 712228648 <+94%2071%20222%208648>
>> Blog: a5anka.github.io
>>
>> <https://wso2.com/signature>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> <http://sanjeewamalalgoda.blogspot.com/>blog
> :http://sanjeewamalalgoda.blogspot.com/
> <http://sanjeewamalalgoda.blogspot.com/>
>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
--
Sasikala Kottegoda
*Senior Software Engineer*
WSO2 Inc., http://wso2.com/
lean. enterprise. middleware
Mobile: +94 774835928
[image: https://wso2.com/signature] <https://wso2.com/signature>
swagger.yaml
Description: application/yaml
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
