Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism
for serializing structured data. Google invented protocol buffers as a refinement
to deficiencies their coders found in both XML and JSON.9
The major refinement of protocol buffers has been to make XML smaller and denser
through the use of a binary encoding. One of the downsides to using XML is that while
it is presented in a human-readable format, it is quite verbose in terms of the amount
of characters that need to be transmitted to convey the same information that one would
with a comparative binary format. This in fact was one of the arguments against using
NETCONF (versus SNMP) in the early days of NETCONF. Recall that we discussed the
relative merits of these earlier, and one of those was the speed at which SNMP could
process requests due to its compact, binary format. While it was in a compact format,
searching for which information to act on could take considerable time. Approaches
such as those in protocol buffers do not necessarily suffer from either limitation. However,
in general, the question one has to ask when comparing these approaches is
whether or not the compactness outweighs the ability for humans to quickly inspect
and understand the text. One way to help decide is whether or not the format will be
used for internal or external APIs. In general, the consensus seems to be that it’s a good
idea to use binary-encoded APIs only for internally consumed APIs and use humanreadable
ones (i.e., XML, JSON, etc.) for public-facing ones.