[rabbitmq-discuss] AMQP-RPC vs REST
static.void.dev at gmail.com
Tue Oct 30 17:58:38 GMT 2012
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.
> 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:
> 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
>>>> processing though it seems like using simple HTTP to a RESTful service
>>>> 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
>> This is all just a long-winded way of repeating what Alexis says above
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss