OData is a new API protocol that has recently been released by Microsoft, along with the launch of their new site on the 16th March 2010. It is a RESTful standard, which adds a lot of its own goods to the table.

As a RESTful standard, it exposes a web service in the form of resources accessible via discrete HTTP urls, representing actions via the HTTP methods. It fills in the gaps that the REST style of architecture leaves open, giving a full specification, from the request to the response (although omitting authentication and authorisation). OData surprisingly also allows RPC-style operations as well.

In essence, OData is as to RESTful service style as SOAP is to RPC. Before this, I had a hard time taking REST seriously, given the lack of protocol specifications meaning that each implementation of a RESTful service tends to handle things differently.

It also includes features that make it much more ready for the enterprise environment, supporting:

• a service definition language
• error message formatting – missing from the documentation at the moment
• dataset paging
• advanced queries
• batch requests

There are two request and response body formats which are supported, AtomPub and JSON.

Features

Providing a web-service description language, it allows automatic creation of proxy classes for clients to quickly consume with little knowledge of the service. It also allows a level of client-side validation of a request before it is sent out.

If an error occurs, as with the REST architecture style, OData producers will use HTTP error statuses 4xx/5xx to notify of an error, however this information is not usually enough to help the consumer bug fix, so OData defines an error message specification which is sent in the response body.

A frequent problem faced when building a web-service that lists entries is that it becomes a problem when the number of entries gets large. Asside from the fact that not all HTTP servers are built for long streams of data, the consumer does not need all of that information at once, so paging is required to limit the response. OData defines this ability in its specification.

Web services in a REST architecture tend to have limited functionality in an individual request. As such, additional resources are needed to define complex transactions. This means that the web-service needs multiple calls to different resource actions. OData improves this by allowing multiple calls to be batched into one request, removing the HTTP overhead associated.

GData protocol

If you have ever used any of Google’s API’s you may think this sounds very similar to the Google GData protocol, which has similar features. Google released the GData protocol for access to it’s services, such as Calendar, Docs, and YouTube API.

GData is really only pushed as a protocol to be consumed for Google’s services, however OData appears to be an attempt to open the server side of the protocol for other companies to use, providing much more for developers who wish to develop a OData producer, including .Net libraries to help expose data in the protocol.

OData SDK

Microsoft has also provided as part of it’s OData SDK, along with the .Net server libraries, client libraries for most major languages (Javascript, PHP, Java, Objective-C, Silverlight, and obviously .Net), so is ready immediately for several of Microsoft’s services, including Azure.

Aside from the disappointment of no PHP server libraries for this (of which I may try to rectify myself by creating my own), the new web-service protocol appears to be the best thing since SOAP, if not better, and may even replace it as my prefered choice in web-service development.

See more information at:

• http://www.odata.org/