Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have REST webservices that can serve XML or JSON (WCF). I'm toying with idea of implementing Protobufs. Why?

PROS

  1. Less load on servers.
  2. Smaller message size - less traffic.
  3. It is easier to switch now than later.

CONS

  1. Need to be implemented
  2. Going to be harder to troubleshoot/sniff messages for debugging.
  3. I can enable GZip on server and JSON will consume as much traffic

What is your suggestion and/or experience on this?

share|improve this question
1  
I looked at the wikipedia page, and was actually more chars per key-value pair, so why dose it have smaller messages? –  Kahil Jun 22 '12 at 16:18
    
Because of serialization. Binary data comes through as binary (byte arrays for example). In addition, it doesn't carry property names in a message. They go by property ordinals. developers.google.com/protocol-buffers/docs/encoding#structure –  katit Jun 22 '12 at 16:24
7  
Technically you answered your own question, compress the JSON and be done with it. Most importantly you never mention an actual business case for spending money and time on this activity. –  Jarrod Roberson Jun 22 '12 at 16:41

2 Answers 2

up vote 19 down vote accepted

Does the business value of implementing them exceed the cost?

If you implement, you need to change not just your server, but all clients (although you can support both formats and only change clients as needed). That will take time and testing, which is a direct cost. And don't underestimate the time taken to really understand protocol buffers (especially the reasons to make field required or optional), and the time taken to integrate the protobuf compiler into your build process.

So does the value exceed that? Are you faced with a choice of "our bandwidth costs are X% of our revenues and we can't support that"? Or even "we need to spend $20,000 to add servers to support JSON"?

Unless you have a pressing business need, your "pros" aren't really pros, just premature optimization.

share|improve this answer

i maintain apis and somebody before me added protobuf (because it was "faster"). The only thing faster is RTT because of of smaller payload, and that can be fixed with gzipped JSON.

The part that is distasteful to me is the relative work to maintain protobuf (compared to JSON). I use java so we use Jackson object mapping for JSON. Adding to a response means adding a field to a POJO. But for protobuf I have to modify the .proto file, then update the serialization and deserialization logic which moves the data in/out of the protocol buffers and into POJOs. It's happened more than once that a release has happened where someone added a field and forgot to put in either the serialization or deserialization code for the protocol buffers.

Now that clients have implemented against the protocol buffers, it's almost impossible to get away from.

You can probably guess from this, my advice is don't do it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.