Spring REST @MVC: Add support for google Protocol Buffers resource representation format [SPR-5807]

[spring-projects-issues]

Keith Donald opened SPR-5807 and commented

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.

---

Affects: 3.0 M3

Issue Links:

• Support Protobuf serialization in WebFlux [SPR-15776] #20331 Support Protobuf serialization in WebFlux
• Spring MVC REST: Support for Google Protocol Buffers View [SPR-6258] #10926 Spring MVC REST: Support for Google Protocol Buffers View ("supersedes")
• Spring MVC REST: Support for binding Google Protocol Buffers messages [SPR-6259] #10927 Spring MVC REST: Support for binding Google Protocol Buffers messages ("is superseded by")
• Spring MVC REST: Provide RestTemplate support for receiving & sending Google Protocol Buffers Messages [SPR-6260] #10928 Spring MVC REST: Provide RestTemplate support for receiving & sending Google Protocol Buffers Messages ("is superseded by")
• Spring MVC REST: Provide interface definition model for generating HTTP client interface proxies wrapping RestTemplates [SPR-6261] #10929 Spring MVC REST: Provide interface definition model for generating HTTP client interface proxies wrapping RestTemplates ("is superseded by")

Referenced from: commits b56703e

15 votes, 21 watchers

[spring-projects-issues]

Mingfai Ma commented

+1, maybe implement the Protocol Buffer transport for Spring Remoting / HTTP Invoker first.

[spring-projects-issues]

Alex Antonov commented

Added a pull-request for the Converter implementation (might need some tweaking to better fit the Spring programming model) - #577

[spring-projects-issues]

Rossen Stoyanchev commented

Moving to RC2 since we didn't get enough time to integrate with our build system.

[spring-projects-issues]

Brian Clozel commented

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 robwinch, maybe do you have ideas to make this part of the gradle build look better?