Thou shall not do OData and I'll explain why

October 1, 2018 by rdagumampan

Today I had great time hearing various arguments on pros and cons of OData in our services. Some of our team mates shared the pain of changing interfaces to accomodate fast chaning business requirements and concerns on future maintenance costs to support new capabilities. They also argued if we expose OData in our internal APIs, the clients would only have to draft the right query and would only have to do this once to satisfy all future queries.

Well, I’m not a big fan of OData. My first argument is if we want to use OData, then lets just do Link Servers and expose a View from SQL Server and its done, problem solved right?. Dumb. Of course that’s not all :).

While I agree that OData gives enourmous power to clients to query data in many possible ways, IMO OData is like a Swiss army knife we give to clients and hoping they use it right. I think instead, we must design services that states a clear intent, description and behaviour. To reduce future changes, we invest time on good service design and modeling. To accelerate change requests, we develop accelerated delivery pipeline and we gauarantee APIs are sufficiently tested and regressed. We also make code accessible that anyone can fork, implement new API and create pull requests to API maintainer. To protect from technology obsolescence, we must create the right abstraction and reduce tight dependency to a technology like EF. And to do as minimal work as possible, we don’t solve all future problems but strive to continuously deploy a common and fit-for-purpose API.

But its maintenance hell!

Yes, there will be additional work, the clients will have the tendency to be chatty and api users may receive data more than they need. But changes are inivetable and APIs like all other services dependent on changing information model and requirements will have to follow its natural course and lifecycle. When we have new requirement, we extend the existing interface or create a new version to support compatibility to existing systems. Note that its the same course we follow with Databases, Messages, Topics, WS/SOAP and code functions.

When can i recommend OData?

I would recommend OData for open data platforms where we allow data users to query data in whatever way possible. For example, exposing wind data and some measurements for analytics of the academic and scientific community. This maybe the primary driver for the adaption of OData in government open data portals. Also if our compliance agreement demands that we share our raw data to our investors and partners, OData would be a good alternative.

Can we have a middle ground here?

We can use OData interface to support our data analysts and data scientists so they can have freedom to run their models and do regressive tests with all the accessibility and filtering features of OData.

But for service-to-service integration, No. :) //2c

What is the industry sentiment?

The general sentiment is mixed with big brothers SAP, Microsoft and Oracle running the show while Netflix and Ebay closed window to OData years ago. Evidently, OData failed to gain traction over 10-years. At this rate and with new techniques emerging and gaining traction like GraphQL, I foresee OData to slowly die and forgotten in the next 3-5 years.

Some parting words

With REST/OData
  $filter=level eq 'guru'

With native REST/API
 level: "guru"


© 2017 | About | Contact | Follow me on Twitter | Powerered by Hucore & Hugo