Please login to post comment

Understanding OData

  • Amruta Bhaskar
  • Jul 13, 2021
  • 0 comment(s)

OData (Open Data Protocol) is an OASIS standard that defines the best practice for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats and query options etc. OData also guides you about tracking changes, defining functions/actions for reusable procedures and sending asynchronous/batch requests etc. Additionally, OData provides a facility for extension to fulfil any custom needs of your RESTful APIs.

OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools. Some of them can help you interact with OData even without knowing anything about the protocol.

To bring this concept to life, let’s use a simple example. Say you have a database of books that you want to make available over an API.

If you GET /books, you get a listing of all the books. If you POST a book, a new book is added to the database and you get back its book ID. If you GET /books/, you get the individual book with ID . If you PUT to an existing book ID, you can edit it.

This is a REST API and it’s pretty useful to put between a user interface and a database.

  • OData is an extension of the idea to allow you to, for instance:
  • Ask only for a particular field of the book object. GET /books(1450)/Title
  • Request a book together with its linked author object. GET /books(1450)?$expand=author
  • Request all books published in May of 2014. GET /books?$filter=Published le 2014-05-31 and Published Ie 2014-05-1

These more advanced capabilities in the API allow the user interface programmers to answer questions better and more easily.

OData makes it much smoother and easier to query and share data between unconnected systems. Using an OData API, you can enable data from one application to interoperate with the other applications you use.

And, in the process, you remove data siloes. So, you can merge all your various data sources into a single, consolidated view. This increases the shared value of your data, allowing you to gain faster and more powerful insights.

OData works with a ton of tools. Think databases, business intelligence (BI) systems, CRMs, analytics platforms, even your bespoke in-house applications if you’re up to a little programming. This level of connectivity between systems creates vast BI and reporting opportunities.

You can set up all manner of reports, spreadsheets, dashboards, or web displays. And, because your data can be frequently and automatically queried, you get your results dynamically. (Rather than slow, clunky, manually generated data exports.)

With the vast amount of data from web browsers, mobile apps and business intelligence tools, how could you possibly combine all of this disparate data and make use of it in applications? The monumental task of crafting unique code for every different data source to create a unified, robust application discourages organizations from approaching serious application development.

What OData does is take this interconnected ecosystem of data from all these disparate sources and builds upon existing web standards to facilitate simple, high calibre data connectivity. These standards enable greater efficiency than ever before in everything from custom applications, to cloud storage, to content management.

The best part about OData is that it is basically a standardized REST interface. So, when you think OData, you should also think REST/JSON. This enables you to use the OData standards with any RESTful interface—whether you are programming in Android, iOS, Salesforce Connect or other similar interfaces.

Dissecting OData Technology

Feeds (collections of typed entries) are at the center of OData. Every entry is represented by a structured record with a key that holds a list of properties of both primitive and complex types. Entries can be part of a hierarchy and can also have related entries and related feeds through links. OData services also have the ability to expose Service Operations (simple, service-specific functions that accept input parameters and return entries or complex/primitive values).

In order to find the shape of an OData Service along with its structure, known links and service operations, OData services also expose a Service Metadata Document. These documents describe a given service’s Entity Data Model (the underlying abstract data model used by OData services to formalize the description of the resources it exposes).

Four Fundamentals of OData

In its most basic form, the OData model is fundamentally broken down into four different pieces:

  • The OData Data Model—The OData Data Model is a server-side model, meaning that the data set is only available on the server and the client only knows the currently visible (requested) data. Operations, such as sorting and filtering, are done on the server. The client sends a request to the server and shows the returned data.                          Another key aspect of the model is an OData metadata document. They describe the Entity Data Model (EDM) for a given service, which is the underlying abstract data model used by OData services to formalize the description of the resources it exposes.
  • The OData Protocol—This enables clients to make requests and retrieve responses from an OData service. This includes CRUD operations and OData defined query language. An OData service can be represented in XML-based format defined by Atom/AtomPub or in JSON.
  • OData Client Libraries—OData libraries enable you to quickly and easily access and produce OData APIs. They exist for all kinds of interfaces including .NET, Java, C++, JavaScript, Python, Objective C, iOS and more.
  • An OData Service—Simple OData services may consist of just a feed. More sophisticated services can have several feeds, and in that case it is useful to expose a service document that lists all the top-level feeds so clients can discover them and find out the addresses of each of them. For example, this URI,, identifies the service document for a sample OData service.
Please login to post comment

( 0 ) comment(s)