When it comes to moving data back and forth between an API endpoint and its clients, there are times where a typical RESTful API that relies on JSON simply won't do. This is because RESTful APIs that serialize their data with text-based formats like JSON are slow compared to APIs that go the binary route for serializing their data. On the downside, the binary payloads are impossible to read with the human eye. But sometimes, performance trumps issues like defacto standard compliance and readability.
For example, most people know that the popular application Evernote has an API. But, unless you've looked at it, you wouldn't know that it's not a RESTful API. As applications go, one of Evernote's biggest advantages is the way it keeps all its clients and apps in quick synch with Evernote's cloud. But, in order for Evernote to manage that synchronicitity on a timely basis, it had to dispense with the idea of a RESTful API and instead went with one that serializes the data in a binary format using Apache Thrift. As a result, Evernote also gained from one of Thrift's distinct benefits; automatic SDK generation for some common languages like C#, Java, Javascript, PHP, Python and Ruby (and some not so common ones like Haskell and Smalltalk). Instead of working directly with Evernote's Thrift-based API, developers rely on those SDKs to handle the serialization and deserialization of Evernote's data payloads into (and from) Thrift's binary data format.
Thrift is not the only choice. The Apache Foundation also offers Avro. Then, there's Google's Protocol Buffers as well as lesser-known solutions like Upper Setting's FASTack. This tutorial is for API providers who want marry the benefits of Google Protocol Buffers-based binary serialization to Microsoft's ASP.NET Web API framework for providing API endpoints. Out of the box, the .NET Web API framework provisions a RESTful API. But after reading this tutorial, you'll be able to substitute Google's Protocol Buffers for that Web API's RESTful default.