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}/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* <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
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
