In the world of SAP integrations, the term “oData” is thrown around quite liberally. For people who are not in the development trenches, it is often unclear what oData exactly is. This article is primarily oriented towards IT executives who wish to get a high-level understanding of oData and where oData is used. The discussion below assumes a basic understanding of what APIs are (if you don’t, check out https://www.howtogeek.com/343877/what-is-an-api/).
Before the great days of the Internet, if one developer came up with better way to do something and wanted to share (or sell) it to other developers they would package it as a “software library” or a “software component” and physically give the other developer the files via disk (usually in a form of a .dll or .so file). Application developers could then bundle this library into their applications and use the features of that component via the component’s API.
Like so many other things, the Internet also had a dramatic impact on the delivery of APIs and even the nature of how they are constructed. At first, the Internet made it easy to build a website with a link to allow application developers to download an DLL files for their use. However, as data became the driving force behind the Internet, the development community created “web services” which are APIs that you don’t download but rather “call” over the Internet. This allows callers of those web services to not only take advantage of the logic the API provides but also the data that goes along with it, as well as any bug fixes and enhancements to the API. For example, think of a “web service” that allows a developer to pull the current weather for any location in the US. While the “logic” of the service is important, it is the real-time data from that service that is the most valuable component.
Having standards on how to communicate is important and one of the standards for computer programs to talk to each other when using web services is REST. The type of data returned from a REST web service is typically HTML, JSON or XML. While HTML is typically intended for human viewing purposes, JSON and XML are intended for consumption by other programs. To see an example of a REST service in action, click on this link to the weather API for weather.gov: https://api.weather.gov/. Without passing it any additional information, it will return data in “JSON” format on the status of the service that your browser should nicely display for you in your web browser. Try adding the word “alerts” to the end of that URL to see what data you now get in JSON format (https://api.weather.gov/alerts).
OData further extends the REST format by providing some high-level structure. In many ways it is similar to the way a textbook provides a high-level organizational structure about its content. Without a table of contents, chapters, page numbers, or index it would be a lot harder to understand the purpose of the book and how to find the specific information you are looking for.
Let’s call the “organizational” data about the book, but not the actual book content, “meta” data. In other words, metadata it is data that describes the “real” data. oData defines a set of standard rules for the type of metadata that developers of REST services need to provide as part of a Web Service. If a web service uses OData standard, it makes it easier for other applications to discover what the service is about, what data it contains and what you can do with that service. It also prescribes how certain operations should be performed on the service. For example, if you provide a list of orders with certain data elements, I should also be able to query and filter the list of orders using pre-determined methods.
When a Web Service supports oData, the data that that service provides can be leveraged by a large ecosystem of applications that need this data. Examples are certain analytics suites for SAP Cloud Platform – they can use oData standard to access data securely from on-premise SAP system in real-time.
OData is an open standard and is supported by many large companies like SAP, Microsoft, and IBM who have incorporated oData support to many of their products. This is important to organizations in the SAP landscape because it means that developers can write applications in different programming languages, such as Javascript (e.g. Fiori), Microsoft C# or Java, and seamlessly interact with oData services running on your Netweaver Gateway. Further enterprises can build oData services to expose data on non-SAP platforms, then consume them from SAP Cloud Platform or any other oData supporting software, framework or system.
The website of oData itself: https://www.odata.org/
A fabulous one I highly recommend to all IT proffesionals that want to dive into oData. If you already comfortable with REST web services, skip ahead to part 3:
https://blogs.sap.com/2016/02/08/odata-everything-that-you-need-to-know-part-1/
oData talked about in technical detail from a perspective of a Microsoft developer. http://www.software-architects.com/devblog/2014/09/12/10-OData-FAQs#header7.