[rabbitmq-discuss] AMQP-RPC vs REST

[Mark]

Thanks everyone for your responses. I have a lot to digest now :)

On Oct 30, 2012, at 8:18 AM, Alexis Richardson <alexis at rabbitmq.com> wrote:

> 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
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss