+1. That looks good.

Thanks,
sanjeewa.

On Thu, Mar 8, 2018 at 11:08 AM, Asanka Abeyweera <asank...@wso2.com> 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 <sanje...@wso2.com>
> 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 <asank...@wso2.com>
>> 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
>>>> <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 <hars...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 12, 2018 at 9:35 AM, Asitha Nanayakkara <asi...@wso2.com>
>>>>> 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 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 <asank...@wso2.com>
>>>>>> 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 <
>>>>>>> eran...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Asitha,
>>>>>>>>
>>>>>>>> Thanks for the explanation.
>>>>>>>>
>>>>>>>> On Wed, Jan 10, 2018 at 10:29 PM, Asitha Nanayakkara <
>>>>>>>> asi...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Eranda,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jan 10, 2018 at 6:47 PM, Eranda Rajapakshe <
>>>>>>>>> eran...@wso2.com> 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 <
>>>>>>>>>> asi...@wso2.com> 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 <
>>>>>>>>>>>> sanje...@wso2.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:40 PM, Asitha Nanayakkara <
>>>>>>>>>>>>> asi...@wso2.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adding Harshak, Sanjeewa and Malinthaa
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jan 10, 2018 at 5:37 PM, Asitha Nanayakkara <
>>>>>>>>>>>>>> asi...@wso2.com> 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}/dest
>>>>>>>>>>>>>>> inations { "name": "queueName", "durable": true,
>>>>>>>>>>>>>>> "autoDelete": false }
>>>>>>>>>>>>>>> 6 List Queues/Topics GET /exchanges/{exchangeName}/dest
>>>>>>>>>>>>>>> inations
>>>>>>>>>>>>>>> 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}/con
>>>>>>>>>>>>>>> sumers
>>>>>>>>>>>>>>> 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* <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
>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>> 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
>>>>>>>> Architecture@wso2.org
>>>>>>>> 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
>>>>>> Architecture@wso2.org
>>>>>> 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
>>>>> Architecture@wso2.org
>>>>> 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
>>>> Architecture@wso2.org
>>>> 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
>>> Architecture@wso2.org
>>> 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
>> Architecture@wso2.org
>> 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
> Architecture@wso2.org
> 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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to