AMQP-RPC vs REST

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

AMQP-RPC vs REST

Mark
It seems to me that AMQP-RPC may be a bit overkill these days when when one could simply use REST and JSON. Thoughts?
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AMQP-RPC vs REST

Alexis Richardson-5
On Mon, Oct 29, 2012 at 8:59 PM, Mark <[hidden email]> wrote:
> It seems to me that AMQP-RPC may be a bit overkill these days when when one could simply use REST and JSON. Thoughts?

Not sure what you mean?
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AMQP-RPC vs REST

Mark
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 (http://www.rabbitmq.com/tutorials/tutorial-six-python.html) Just wondering how many of you out there are using AMQP when it comes to RPC and/or connecting services.

On Oct 29, 2012, at 3:29 PM, Alexis Richardson <[hidden email]> wrote:

On Mon, Oct 29, 2012 at 8:59 PM, Mark <[hidden email]> wrote:
It seems to me that AMQP-RPC may be a bit overkill these days when when one could simply use REST and JSON. Thoughts?

Not sure what you mean?
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AMQP-RPC vs REST

Alexis Richardson-5
On Mon, Oct 29, 2012 at 10:42 PM, Mark <[hidden email]> 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" :-)

I don't think you can use words like "simple" without qualifying them
by a use case.

What if the backend service doesn't expose HTTP, or does not benefit
from direct access by clients?





> (http://www.rabbitmq.com/tutorials/tutorial-six-python.html) Just wondering
> how many of you out there are using AMQP when it comes to RPC and/or
> connecting services.
>
> On Oct 29, 2012, at 3:29 PM, Alexis Richardson <[hidden email]> wrote:
>
> On Mon, Oct 29, 2012 at 8:59 PM, Mark <[hidden email]> wrote:
>
> It seems to me that AMQP-RPC may be a bit overkill these days when when one
> could simply use REST and JSON. Thoughts?
>
>
> Not sure what you mean?
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AMQP-RPC vs REST

Laing, Michael P.
We use RPC a lot - async of course.

Though as our services get more reliable we are chaining together message
'pipelines' and re-routing/handling the few exceptions instead.

Our new stuff is http-free, actually. Websockets to the client; amqp (and
some zmq) otherwise. Plus s3 and DynamoDB and other AWS services.

OK... initial connection is http but then we upgrade.

Michael Laing

On 10/29/12 7:09 PM, "Alexis Richardson" <[hidden email]> wrote:

>On Mon, Oct 29, 2012 at 10:42 PM, Mark <[hidden email]> 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" :-)
>
>I don't think you can use words like "simple" without qualifying them
>by a use case.
>
>What if the backend service doesn't expose HTTP, or does not benefit
>from direct access by clients?
>
>
>
>
>
>> (http://www.rabbitmq.com/tutorials/tutorial-six-python.html) Just
>>wondering
>> how many of you out there are using AMQP when it comes to RPC and/or
>> connecting services.
>>
>> On Oct 29, 2012, at 3:29 PM, Alexis Richardson <[hidden email]>
>>wrote:
>>
>> On Mon, Oct 29, 2012 at 8:59 PM, Mark <[hidden email]> wrote:
>>
>> It seems to me that AMQP-RPC may be a bit overkill these days when when
>>one
>> could simply use REST and JSON. Thoughts?
>>
>>
>> Not sure what you mean?
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> [hidden email]
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> [hidden email]
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>_______________________________________________
>rabbitmq-discuss mailing list
>[hidden email]
>https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AMQP-RPC vs REST

Gordon Sim-2
In reply to this post by Alexis Richardson-5
On 10/29/2012 11:09 PM, Alexis Richardson wrote:
> On Mon, Oct 29, 2012 at 10:42 PM, Mark <[hidden email]> 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
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: AMQP-RPC vs REST

Alexis Richardson-5
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 <[hidden email]> wrote:

> On 10/29/2012 11:09 PM, Alexis Richardson wrote:
>>
>> On Mon, Oct 29, 2012 at 10:42 PM, Mark <[hidden email]> 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
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> wrote:
>> On 10/29/2012 11:09 PM, Alexis Richardson wrote:
>>>
>>> On Mon, Oct 29, 2012 at 10:42 PM, Mark <[hidden email]> 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
>> [hidden email]
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> _______________________________________________
> rabbitmq-discuss mailing list
> [hidden email]
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss