17 June 2013

Netflix has abandoned OData – does the standard have a future without an ecosystem?

Netflix have issued a rather low key statement recently to announce that they are closing their OData catalogue. EBay also seem to have quietly put their own implementation out to grass as the documentation has gone missing and nobody seems to know where the end-points are. With a shrinking ecosystem and no marquee implementations, does Microsoft’s data standard have a future?

OData was originally designed by Microsoft to standardise the way in which basic data access operations can be made available via REST. It’s built on top of Atom protocol and extends it by adding metadata to describe the data source and a standard means of querying the underlying data. Although the first few versions were very much led by Microsoft, a new version of the standard is currently being developed by OASIS.

Can a Microsoft standard ever gain traction?

Although numerous client and server libraries have been created to ensure cross-platform support, what little traction exists for OData seems to be confined to the .Net space. Despite the recent involvement of OASIS, the association with Microsoft may ultimately undermine support for the standard as many open data advocates are still suspicious of their motives.

This is hardly surprising after the perceived “embrace, extend and extinguish” strategy of the 1990s where Microsoft were accused of adding proprietary features to open standards in order to gain unofficial ownership of them.

Microsoft has come a long way since Steve Ballmer declared that “Linux is a cancer” back in 2001. They have embraced numerous open source technologies as well as making some significant contributions of their own. However, a lingering suspicion is likely to remain around any standard that has its origins in Redmond.

The dangers of a “magic box”

A more technical concern with OData is that it encourages poor development and API practices by providing a black-box framework to enforce a generic repository pattern. This can be regarded as an anti-pattern as it provides both a weak contract and leaky abstraction.

An API should be designed with a specific intent in mind rather than providing a generic set of methods that are automatically generated. OData tends to give rise to very noisy method outputs with a metadata approach that feels more like a WSDL than REST. This doesn’t exactly foster simplicity and usability.

More importantly, the IQueryable interface provides a contract so vague and wide that it is rarely implemented fully – hardly surprising given that Microsoft’s own guide for building an IQueryable provider runs to eighteen articles. It allows remote clients to execute database queries remotely over HTTP which can only give rise to complex and fragile integrations that break under the weight of edge case problems.

OData slips comfortably over the Entity Framework in .Net making it easy to expose data entities as REST resources. This encourages you to expose internal implementation details by tightly coupling a public service definition to the underlying database system. The lack of any clear abstraction between services and underlying data will leave client integrations even more vulnerable to data changes.

The .Net implementation of OData feels like a “magic box” solution. It conceals too much implementation detail from developers and designers which can only serve to store up trouble for the future. It doesn’t feel appropriate for public-facing services or complex data models that need more carefully curated API definitions.

The right idea but the wrong sponsor?

Many of these criticisms are largely about an implementation rather than the standard itself. There are a lot of things that OData does well. The output may be a little verbose, but it does provide elegant query syntax that lends itself well to surfacing small data models through HTTP. It could be useful for internal scenarios with predictable usage patterns.

When it comes down to it, an imperfect standard may be preferable to trying to cobble together numerous badly-designed APIs. There is a lot to be said for standardising the way common data manipulation operations are carried out over HTTP. It’s a noble ambition that can help to streamline system integrations and promote greater connectivity and interoperability.

However, this ambition does rather depend on widespread adoption and it’s not certain that a standard with Microsoft origins is ever likely to achieve sufficient traction. Microsoft is likely to continue to push an OData .Net implementation as its Web API stack evolves, but any wider adoption will depend very much on the next, OASIS-led iteration of the OData standards.

Filed under Architecture, Design patterns, Net Framework, REST, Web services.