[SPR-5807] Spring REST @MVC: Add support for google Protocol Buffers
resource representation format Created: 05/Jun/09 Updated: 22/Sep/15 Resolved: 22/Jul/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Closed
Spring Framework
Remoting, Web
3.0 M3
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
New Feature
Keith Donald
Complete
None
Not Specified
Issue Links:
Supersede
supersedes
4.1 RC2
Priority:
Assignee:
Votes:
Major
Brian Clozel
15
Not Specified
Not Specified
is superseded
by
is superseded
by
is superseded
by
SPR6258
SPR6261
SPR6259
SPR6260
Spring MVC REST: Support for Google
P...
Spring MVC REST: Provide interface
de...
Spring MVC REST: Support for
binding ...
Spring MVC REST: Provide
RestTemplate...
Resolved
Open
Resolved
Resolved
1 year, 29 weeks, 1 day ago
Days since last
comment:
Last commented false
by a User:
Juergen Hoeller
Last updater:
Description
Google Protocol buffers provide a mature, high-performant binary data exchange protocol that
can be used a an alternative to JSON and XML to connect systems over a REST interface.
Benchmarks outlined by by Orbitz and Sears at JavaOne 2009 have shown that marshaling
using protocol buffers is up to 7 to 10 times faster than JSON. This would make them a good,
lightweight choice for Java-to-Java remoting over HTTP/REST.
This ticket should investigate adding support for Google protocol buffers on the server-side side
with Spring @MVC, and on the client-side with REST-template possibly with some sort of
dynamic proxy layer on top.
See http://code.google.com/apis/protocolbuffers/ for the Google Protocol Buffers project home
page.
Comments
Comment by Mingfai Ma [ 27/Jun/09 ]
+1, maybe implement the Protocol Buffer transport for Spring Remoting / HTTP Invoker first.
Comment by Alex Antonov [ 01/Jul/14 ]
Added a pull-request for the Converter implementation (might need some tweaking to better fit
the Spring programming model) - https://github.com/spring-projects/spring-framework/pull/577
Comment by Rossen Stoyanchev [ 17/Jul/14 ]
Moving to RC2 since we didn't get enough time to integrate with our build system.
Comment by Brian Clozel [ 21/Jul/14 ]
I've cleaned a bit the protobuf PR, and 3 questions remain:
Supported media types
I'm wondering if we should also support *+json / *+xml or if custom mediatypes don't make
sense in that case
Content-Length HTTP response header
I've deleted the getContentLength method implementation because:




it requires to serialize twice the same message - this is a performance issue
we're doing the same thing anyway for Jackson and other message converters
I did not find anything saying that Protobuf implementations don't support chunked
encoding
using a ShallowEtagFilter is a known workaround for this
Gradle build
I've checked in message classes generated by the protoc - I know this is a bad practice, but I'm
trying here not to introduce some hard system requirement for all contributors. I've created a
profile that can be used to re-generate those. I know that Alex Antonov's gradle protobuf plugin
can write those generated files in another folder, but it looks like Gradle got confused with
inputs/ouputs when trying to write those directly in our src folder. In any case, Alex Antonov
and Rob Winch, maybe do you have ideas to make this part of the gradle build look better?
Generated at Wed Feb 10 00:12:16 UTC 2016 using JIRA 6.4.11#64026sha1:78f6ec473a3f058bd5d6c30e9319c7ab376bdb9c.