Avro RPC

[Mark <st...@gmail.com>]

Very basic question but could one explain why one would choose Avro RPC over something like a simple restful service over HTTP? 

The only thing I can think of is it adds a little more structure to the request/response and slightly more compact. Other than that, I'm drawing a blank. As far as the response goes though, couldn't you simply return an Avro message from a restful http service and have the client parse it if you wanted more structure?

Thanks for the clarification

-M

Re: Avro RPC

[Connor Doyle <co...@gmail.com>]

In the parlance of the relevant section of the Avro specification ("Protocol Wire Format"), I'm talking about a stateful connection.  The agreed-upon client and server protocol versions are part of the connection state, as are the pending requests at each client.  By tagging each request with a sequence number we can allow responses to roll in asynchronously.  We encode this identifier as an Avro long in the metadata map sent with each message, as laid out in the spec for the call format.  In our case, we're using a web socket connection as the transport layer.
--
Connor

On May 29, 2013, at 12:50, Mark <st...@gmail.com> wrote:

> Didn't know Avro RPC could maintain a persistent connection. Would you mind elaborating on your use case?
> 
> On May 29, 2013, at 10:08 AM, Connor Doyle <co...@gmail.com> wrote:
> 
>> Avro RPC can be _dramatically_ more compact, especially when used over a persistent connection.  We use binary avro RPC over a WebSocket connection.  The overhead for each request is a tiny blob of metadata and the message name.  This compares very favorably with a full set of HTTP headers for each message.  Another advantage we see is that with a persistent connection we can handle responses asynchronously; quickly serviced requests don't have to wait for slow ones.  It all depends on the details of your use case, however.
>> --
>> Connor
>> 
>> On May 29, 2013, at 11:30, Mark <st...@gmail.com> wrote:
>> 
>>> Very basic question but could one explain why one would choose Avro RPC over something like a simple restful service over HTTP? 
>>> 
>>> The only thing I can think of is it adds a little more structure to the request/response and slightly more compact. Other than that, I'm drawing a blank. As far as the response goes though, couldn't you simply return an Avro message from a restful http service and have the client parse it if you wanted more structure?
>>> 
>>> Thanks for the clarification
>>> 
>>> -M
> 

Re: Avro RPC

[Mark <st...@gmail.com>]

Didn't know Avro RPC could maintain a persistent connection. Would you mind elaborating on your use case?

On May 29, 2013, at 10:08 AM, Connor Doyle <co...@gmail.com> wrote:

> Avro RPC can be _dramatically_ more compact, especially when used over a persistent connection.  We use binary avro RPC over a WebSocket connection.  The overhead for each request is a tiny blob of metadata and the message name.  This compares very favorably with a full set of HTTP headers for each message.  Another advantage we see is that with a persistent connection we can handle responses asynchronously; quickly serviced requests don't have to wait for slow ones.  It all depends on the details of your use case, however.
> --
> Connor
> 
> On May 29, 2013, at 11:30, Mark <st...@gmail.com> wrote:
> 
>> Very basic question but could one explain why one would choose Avro RPC over something like a simple restful service over HTTP? 
>> 
>> The only thing I can think of is it adds a little more structure to the request/response and slightly more compact. Other than that, I'm drawing a blank. As far as the response goes though, couldn't you simply return an Avro message from a restful http service and have the client parse it if you wanted more structure?
>> 
>> Thanks for the clarification
>> 
>> -M

Re: Avro RPC

[Connor Doyle <co...@gmail.com>]

Avro RPC can be _dramatically_ more compact, especially when used over a persistent connection.  We use binary avro RPC over a WebSocket connection.  The overhead for each request is a tiny blob of metadata and the message name.  This compares very favorably with a full set of HTTP headers for each message.  Another advantage we see is that with a persistent connection we can handle responses asynchronously; quickly serviced requests don't have to wait for slow ones.  It all depends on the details of your use case, however.
--
Connor

On May 29, 2013, at 11:30, Mark <st...@gmail.com> wrote:

> Very basic question but could one explain why one would choose Avro RPC over something like a simple restful service over HTTP? 
> 
> The only thing I can think of is it adds a little more structure to the request/response and slightly more compact. Other than that, I'm drawing a blank. As far as the response goes though, couldn't you simply return an Avro message from a restful http service and have the client parse it if you wanted more structure?
> 
> Thanks for the clarification
> 
> -M