Everything about OData
For anyone who has embarked on an API journey, it is very likely that you have come across the term OData in the context of API and Integration.
In mine line of work, I interact on daily basis with many stakeholders involved in the API strategy, from Developer to Architects, Product Managers to Executives, and find that the term OData is not understood for what it is. I would like to take this opportunity to clarify what is OData, where does it stand in the API ecosystem and why is it needed.
Big Picture
First off, let’s see where in the API taxonomy chart does OData fit in.
You can see that OData is a type of REST API. This chart will add some clarity to statements like:
- “We are not doing REST, we are doing ODATA”
- “No we are not doing APIs, we have ODATA services”
What is oData?
The official description from Odata.org
OData (Open Data Protocol) is an ISO/IEC approved,
OASIS standard that defines a
set of best practices for building and consuming RESTful APIs.
In short, its one way of implementing REST APIs.
[minor detour: There are no RESTless APIs, RESTful and REST APIs are same]
At the core, REST Architecture models the requirements into Entity-Relationship models and has a well-defined way on how you can interact with these entities. You interact with the entities through CRUDQ operations which stand for Create, Read, Update, Delete, Query. REST is broad architecture principles which can be applied to any technology, it need not just for an HTTP or Web APIs. You can read more on REST at the Wikipedia page.
Why OData?
REST defines the core principles around entity-relationship, operations, session etc. but doesn’t define how to implement them. It gives the REST practitioners a lot of flexibility on to implement the CRUDQ operations as long as there are clear methods to perform these operations on an entity.
Flexibility means an opportunity to implement to best of your needs. This flexibility leads to a lot of variations in API development. And variations means its extra time & cost to consume (use) an API.
OData’s goal is to develop a standard so that there is ONE way to implement a REST API. For simplicity, the below chart conveys what OData is trying to do.
How is OData achieving standardization?
OData defines standards across several categories where REST doesn’t make any recommendations, areas such as how should URL parameters need to be handled, what should be the date formats, how are headers handled, what should be the payload structure etc.
You can get more information on these categories in the documentation section on OData website.
Here I will share one example to show the impact of lack of standardization. Let’s say, you want to provide an API to query Customer data, and the objective is to retrieve all Healthcare customers in the city of Los Angeles.
The below inserts show how many different ways can this simple API be implemented.
The Non REST doesn’t have to be an Entity model, the API endpoints can be a representation of system queries, like “getcustomer” or “bigquery” .
In a REST model, the API endpoint has to be an Entity, but the query parameters can be defined in any way. The entity here is “customers”, and both the implementations that were shown are valid REST.
OData has a very specific definition of how to implement query parameters, so there is only ONE way to implement this, which is by using “$filter” keyword.
Just like the query parameters, OData provides a specification on several attributes of REST APIs and enforces a standard approach to REST API implementation.
Are there any Drawbacks for OData?
Due to a strict discipline on how the payload has to be formatted, OData specification sometimes seems very restrictive. For example, an Entity cannot have an array as a property, it has to be a relation with a different Entity. Order vs OrderItems.
But as the adoption goes up, the OData specification is fast evolving to make it easier to address most common situations and enhance the developer experience.
Opinion
The biggest drawback of not having a standard for REST is lack of Accelerators. In SOA days, every software vendor included an automated way to create a program that can execute a SOAP request, you just feed the WSDL and the proxy gets generated in a fraction of a second. The Application developer has to just take care to pass the right parameters in the right sections.
Due to lack of such tools, some organizations follow up their APIs with an SDK for major programming languages but for most organizations, it is cost prohibitive to provide an SDK for their APIs.
Thanks to OData, they are some very good tools to model and consumer an OData API, especially some flagship products from SAP such as SAP Gateway, HANA platform etc.
Thank you for your time and hope you have enjoyed reading about OData.
Hi Ram
All the pictures (jpg/png) are missing. Links to pictures cant be resolved.
Kindly update accordingly.
Thanks
mick
Hey Mick, thanks for alerting me abt the images, I have updated the post with the images