Overview

1.   Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format.

 

 

2.   You specify how you want the information you're serializing to be structured by defining protocol buffer message types in  .proto files. Each protocol buffer message is a small logical record of information, containing a series of name-value pairs. Each message type has one or more uniquely numbered fields, and each field has a name and a value type, where value types can be numbers (integer or floating-point), booleans, strings, raw bytes, or even (as in the example above) other protocol buffer message types, allowing you to structure your data hierarchically. You can specify optional fields, required fields, and repeated fields.

 

3.   Once you've defined your messages, you run the protocol buffer compiler for your application's language on your .proto file to generate data access classes. These provide simple accessors for each field (like email() and set_email()) as well as methods to serialize/parse the whole structure to/from raw bytes. You'll find a complete reference for using generated protocol buffer code in the API Reference section .

 

4.   You can add new fields to your message formats without breaking backwards-compatibility; old binaries simply ignore the new field when parsing.

 

5.   Protocol buffers have many advantages over XML for serializing structured data:

  a)   simpler

  b)   3 to 10 times smaller

  c)   20 to 100 times faster

  d)   less ambiguous

  e)   generate data access classes that are easier to use programmatically

protocol buffers are not always a better solution than XML – for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, at least in their native format, are not. XML is also – to some extent – self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file).