Sam Pullara writes in his post on Using JAX-RS with Protocol Buffers for high-performance REST APIs:
One of the great things about the JAX-RS specification is that it is very extensible and adding new providers for different mime-types is very easy. One of the interesting binary protocols out there is Google Protocol Buffers. They are designed for high-performance systems and drastically reduce the amount of over-the-wire data and also the amount of CPU spent serializing and deserializing that data.
He illustrates how to use protobufs with JAX-RS showing how extensible JAX-RS is. This is nice. However, apart from all the excellent points debated several months ago on Steve Vinoski's Protocol Buffers: Leaky RPC, this particular usage requires clients and servers to share the protobuf definition, and the media type application/x-protobuf says nothing about that. It would be interesting to see if this approach fares better than, say, using XML with gzip encoding even in a controlled environment.
{ 2 comments… read them below or add one }
Clearly you would have to make the .proto files available to the clients in some fashion. My guess is that you could get them into the WADL file that describes the REST services but I haven’t looked closely at it. As for *requiring* protocol buffers, it is very easy in JAX-RS to offer more than one media-type for coming and going for any particular call and it will do the discrimination for you based on Content-Type and Accept headers. As for actual performance when you stick this inside an HTTP envelope it is hard to say as I don’t have a compelling benchmark to run to compare them. Maybe I will transfer 100 Yahoo BOSS search results over it or something and compare the performance to JSON and XML with and without gzip… would that be an interesting test?
Sam
@Sam: If this approach is needed, I would go for a new custom media type for each resource – otherwise the response becomes opaque and can open security holes. As far as a benchmark is concerned, since protobufs provide more efficient (de)serialization over generic parsers, using a custom XML parser may provide for a better comparison.