The first time I came across the Open Data Protocol (OData) was an article about Project Astoria by Pablo Castro in The Architecture Journal back in 2007. At the time I thought that it was probably just another peripheral technology that I *had to* understand in my role as an architect.
Now the technology is maturing, I thought it was time to get an understanding of the principles of OData, and what are some of the Applications where it might be useful to me in practice. I kept notes as I learned, and used these notes to produce this article. I hope you find it useful as a one-stop reference to get you started with OData.
The OData Web Site says ”The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today.” I think this is underselling it slightly, since OData can also “unlock your data and free it from the silos that exist between organisations today”.
The Open Data Protocol (OData) enables the creation of HTTP-based data services, which allow resources, identified using Uniform Resource Identifiers (URIs) and defined in an abstract data model, to be published and edited by Web clients using simple HTTP messages.
OData is intended to be used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems, and traditional Web sites.
In Pablo’s article he compared the flow of content between a traditional (e.g. asp.net, jsp) application and a modern (Ajax, Silverlight, Flex) application.
Flow of content in traditional and modern Web applications
I work for Microsoft, and OData is a Microsoft Specification released under the Microsoft Open Specification Promise (OSP). OData is not the only specification or technology in this space. In fact similar initiatives are on-going under the general name of Semantic Web.
I see OData as much more specialised than the Semantic Web specifications, being largely focussed on tabular data as opposed to resources generally. It will be interesting to see how things develop (and hopefully) come together in the next few years.
This article is quite long, and I have therefore split it into 4 parts:
Hopefully these articles will show you how to produce and publish an OData Feed, Create relationships between feeds from different sources, analyse OData and finally how to develop a custom OData client. This should give a really good appreciation of some of the possible uses for OData.
As part of my investigation, I also explored creating a custom OData service using WCF Data Services. This gives you more control over your service behaviour than is currently available with SQL Azure, but is more complex and I published a separate article on this here:
Please note that I have not covered updating data using OData in this series.
Written by Nick Hill