[rabbitmq-discuss] AMQP-RPC vs REST

[Alexis Richardson]

Thanks Mike, and Gordon.

Mark,

I hope this is helping.  There are certainly cases where your approach
makes sense too, eg lots and lots of web APIs.

One question is: when is it useful to combine the intermediated and
decoupled approach described below, with an HTTP messaging API?  This
is a common pattern too - lots of "integration brokers" use it.  One
way this is used is to provide an HTTP + messaging interface to a
backend system that does not use HTTP.  There are other patterns too.
The Rabbit HTTP interface is here:
http://hg.rabbitmq.com/rabbitmq-management/raw-file/rabbitmq_v2_8_7/priv/www/api/index.html

alexis





On Tue, Oct 30, 2012 at 9:15 AM, Gordon Sim <gsim at redhat.com> wrote:
> On 10/29/2012 11:09 PM, Alexis Richardson wrote:
>>
>> On Mon, Oct 29, 2012 at 10:42 PM, Mark <static.void.dev at gmail.com> wrote:
>>>
>>> For messaging and asych processing AMQP seeming to fit really well. For
>>> sync
>>> processing though it seems like using simple HTTP to a RESTful service
>>> would
>>> be easier than RPC over AMQP
>>
>>
>> "It depends" :-)
>
>
> Yes, it always does!
>
> While I would think many cases would indeed be best implemented as RESTful
> services, especially where a 'resource oriented' view of the system felt
> natural, I myself would do so not because it is easier (I don't think it
> really is) but for the sake of uniformity.
>
> One benefit of using AMQP even for a strict client-server, request-response
> style conversation, is that it makes it easy to introduce intermediaries to
> process/adapt the request and/or the response as the system evolves. You can
> also easily add in specialised processing for different classes of request.
>
> Of course there is nothing that prevents you doing similar things with HTTP
> also, but in my opinion a brokered solution actually makes it easier; the
> available infrastructure does more of the hard work already.
>
> Long running requests also fit quite well with the notion of explicit
> queuing, though again, I'm not implying that they can't be handled with
> HTTP.
>
> This is all just a long-winded way of repeating what Alexis says above
> though!
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss