Click here to Skip to main content
Click here to Skip to main content

WebAPI follow-up.. what about protocol buffers?

, 3 Feb 2013
Rate this:
Please Sign up or sign in to vote.
A s a follow-up to my previous article about WebAPI , I received an interesting question from a friend on LinkedIn: Is there a way to emit data in Protobuf format?

As a follow-up to my previous article about WebAPI, I received an interesting question from a friend on LinkedIn:  Is there a way to emit data in Protobuf format?  

This one got me thinking... ProtoBuf is short for Protocol Buffers which is a data format technology invented by Google to allow for maximum compression of structured data that can be interpreted by any programming language. Google says: "think XML, but smaller, simpler, and FASTER", and I think they may be right. According to Google's own benchmarks, Protocol Buffer format is 3-10x smaller and 20-100x faster on the wire.

Fortunately, there is a pair of NuGet packages available to help our WebAPI application handle the protocol buffer format. From within my WebAPI application, I can use the NuGet console to install these two packages with the following command:

Install-Package WebApiContrib.Formatting.ProtoBuf

Once this command completes, the protocol buffers library protobuf-net should be installed as well as the appropriate media formatter in the WebApiContrib.Formatting.ProtoBuf library. The next step to configure WebAPI is to configure the application to be aware of the new formatter. This is accomplished with the following command in Application_Start in the global.asax.cs file:

protected void Application_Start(object sender, EventArgs e)
{

    GlobalConfiguration.Configuration.Formatters.Add(
		new WebApiContrib.Formatting.ProtoBufFormatter());

    RegisterRoutes(RouteTable.Routes);
}

Finally, we need to configure the data we are going to transport so that the Protocol Buffers library knows how to serialize it. This is accomplished with a series of attributes on our Team class:

[ProtoContract]
public class Team
{
    [ProtoMember(1)]
    public string City { get; set; }

    [ProtoMember(2)]
    public string Name { get; set; }
}

The ProtoContract attribute tells the serializer that this class can be formatted with protocol buffers. The two ProtoMember attributes assign a location to the properties in the resultant stream of data. The numeric locations identifiers should be continuous and start with one.

With this minor bit of configuration, we can start our application and open Fiddler to easily test our new protocol buffer aware API. If I point Fiddler to the standard location http://localhost:4829/api.my I'll get normal JSON output:

[
{"City":"Philadelphia","Name":"Phillies"},
{"City":"Boston","Name":"Red Sox"},
{"City":"Cleveland","Name":"Browns"},
{"City":"Houston","Name":"Astros"},
{"City":"San Diego","Name":"Chargers"}
]

but if I go into the Composer tab of Fiddler and submit the request with an accept header of application/x-protobuf:

Fiddler Composer - Sending a GET request for Protocol Buffer content

The results returned are the protocol buffer format, not entirely visible to us as text:

Protocol Buffer Formatted ResultSet

We didn't change any of our business logic. We didn't change any of our data access code. By simply adding an additional media formatter, WebAPI was able to handle and format the resultset as requested. What else could you format with WebAPI?  What other request formats could you interact with?  Let me know what you think in the comments below.

License

This article, along with any associated source code and files, is licensed under The Microsoft Public License (Ms-PL)

About the Author

Jeffrey T. Fritz
Telerik
United States United States
A Microsoft MVP, ASPInsider and ASP.NET Developer Evangelist for Telerik. Jeffrey is a software developer coach, architect, and speaker in the Microsoft.Net community. A Pluralsight author and international speaker, Jeffrey makes regular appearances at conferences such as TechEd, DevIntersection, CodeStock, FalafelCon, DevReach and New York Code Camp as well as user group meetings in an effort to grow the next generation of software developers
Follow on   Twitter   Google+

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Mobile
Web01 | 2.8.140718.1 | Last Updated 3 Feb 2013
Article Copyright 2013 by Jeffrey T. Fritz
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid