The OData protocol defines best practices for consuming REST APIs. Flexible and scalable, it facilitates the development and exchange of secure data between hybrid solutions



6 minutes read

The last few years have seen the development of many SaaS applications, which has led to the development of more and more REST APIs. This large-scale development is happening so fast that today, developers spend almost more time on APIs than on building their applications.

With its OData protocol, Microsoft wanted to solve this problem and make it easier for developers to work with APIs. The two interfaces will therefore unite to communicate and exchange data despite different standards and protocols.

We will try to understand a little better the differences and especially the stakes of all this through this article.

What is OData?

OData is the contraction of the expression Open Data Protocol. It is a technical protocol that should not be confused with Open Data, which is the free access and use of certain data by any user. 

To put it simply, OData is an OASIS standard that defines the best practices for creating and consuming RESTful APIs. 

As for the latter, REST is the main component of OData. We will come back to this in more detail in the rest of the article. The current version 4.0 dates from 2013.

OData has the particularity to have an ATOM encoding. As a reminder, ATOM is a text editor developed by GitHub for developers based on the XML format. In addition to that, OData will also support JSON format to represent the resources it exposes. 

To describe the data exposed in an OData service, a high-level of entity data model (EDM) should be used. 

We will consider that an OData resource corresponds to any element of the model that can be exchanged and addressed. We will thus find :

  • Entities such as “customer” or “employee”. They are defined by entity types which are structured thanks to a key 

  • A set of entities 

  • Operations, i.e. a logical execution of a part of a given model 

  • Properties

What is a REST API?

An API or Application Program Interface is a set of definitions and protocols that we use to develop or integrate software into an application. 

In reality, it allows two software programs to communicate through a set of precise rules, whether they have the same language or not. But they are not applications as such.

Indeed, only developers will have access to it and will be able to make it work. An ordinary user will only see the result. 

Today, for example, many sites and applications offer to register directly with your Google or Facebook account. This is only possible thanks to an API.

There are several types of APIs: REST, SOAP… Here, we will focus on REST APIs. However, if you want to know more about APIs, don’t hesitate to read our dedicated article.

The term REST (Representational State Transfer) was put forward in the early 2000s by Roy Fielding, known as one of the main authors of the HTTP specification

A REST service is not an architecture but a set of restrictions that must be taken into account in the software architecture that will be used when creating HTTP web applications

This technology is based on transfer with the use of less bandwidth generally built in Javascript or Python


The Rest APIs allow the development of computer applications by using four basic operations or HTTP requests to access and use data. 

We can specify that it will be possible to associate it with a type of SQL request and an HTTP method. Here is a summary of the operations:

  • CREATE (SQL: INSERT / HTTP: PUT / POST): allows the creation of resources
  • READ (SQL: SELECT / HTTP: GET): retrieve a resource or a collection
  • UPDATE (SQL: UPDATE / HTTP: PUT / PATCH): modify or replace a resource
  • DELETE (SQL: DELETE / HTTP: DELETE): delete a resource or a collection

In practice, we all use many REST APIs every day, either with the various plugins we install on our browsers or when we use (even unknowingly) external services from an application system or another application.  

Today, most APIs are found on SaaS (Software as a service) platforms even if some exist on PaaS (Platform as a service). This implies for companies wishing to offer REST APIs to be able to offer all the features related to the Cloud with a Cloud integration tool that provides connectors and API Rest features. 

What are the Differences between API REST and OData?

Differences in Design Principles

API REST and OData have their own principles that differentiate them. We will highlight these.

REST APIs have six principles or constraints that must be respected.

The obligation to give an identifier to all elements: On the Internet, there is a concept of identification through the URI. The URI is simply an element (a sequence of numbers for example) that identifies a resource.

Linking elements together: This principle refers to HATEOS (Hypermedia As The Engine of Application State Hypermedia). It is important to remember that the conformity judgment of an API can be realized thanks to the Richardson model composed of four levels. 

  • Level 0: RPC: this is the Swamp of POX. This is the simple use of HTTP. There will be only one entry point, that is to say only one URI. Moreover, the only action performed will be a POST action (normally reserved for resource creation). If the API is at this level, it will not be REST but rather SOAP. Indeed, we have seen above that each resource must have its own entry point 
  • Level 1: resource usage. In this case, each resource will have its endpoint. Note that here, all requests are still made in POST
  • Level 2: the use of HTTP verbs, i.e. the CRUD verbs seen previously. The action is no longer part of the URI. It is also at this stage that the status code is set up. As a reminder, these codes indicate whether the HTTP request was successful or not. For example, we can find the code 200 for a successful request or the famous 404 error for a resource that was not found. 
  • Level 3: This is the HATEOS level which is not often reached by most APIs. It is about putting forward links that users can follow to reach their goals. This way, users will be guided on what to do and will not have to read all the API documentation.

Use standard methods: All resources should have the same interface and should respond to standard methods or in other words, HTTP verbs. In addition, to GET or POST, there are also HEAD, DELETE, or OPTION.

Having multiple representations for resources: you need to know how to process the received data. Thanks to the HTTP approach, a client that knows how to interact in a specific format can interact with any resource that can offer a representation in that format.

Stateless communication: the REST API is considered stateless, i.e. the different servers do not have to keep track of the communication contexts

A communication or data transfer is unique and the context must be limited to a simple request. This is due to the number of clients using the API at the same time. If they had to keep something from each request, the memory load would be strongly impacted.

Code on demand: this constraint is optional. It is about giving users the possibility to download executable code. The latter can for example download a javascript or even a flash application to encrypt communications.


On its side, OData uses all the REST principles and has the advantage of being flexible and of being able to adapt to the use that one has.

Differences in Data Transfer

In terms of data transfer, the main difference is that on OData it is possible to transfer ATOM data in addition to XML and JSON data. We can characterize ATOM as the new generation of XML data. 

Usually, it is associated with the notion of flow, i.e. several entries. This is what allows OData to be so extensible. Indeed, it is possible to integrate a tag that did not exist before. You just have to declare the schema beforehand to be able to use it.

Differences between Functions

As we said before, the main function of a REST API is to send messages between client and server via HTTP thanks to basic CRUD requests. With OData, it is also possible to send messages via HTTP. Finally, the main difference lies in the exposure of metadata. There are two different ones: 

  • The document service which uses the ATOM protocol
  • An XML document describing the data model (structure, links…)

The language used for this metadata is called Conceptual Schema Definition Language (CSDL).

What to Choose Between API REST and OData?

The choice between API Rest and OData will always depend on your needs and what you want to do with it

For example, for data retrieval (such as web scraping or data retrieval through URLs), we almost always advise you to choose Rest APIs for their speed and ease of use. 

On the other hand, OData seems to be more suitable when communicating between a system and an application. 

Moreover, its extensibility is synonymous with the customization and therefore a greater capacity to meet your needs. If your needs are very specific, OData is the right technology for you.

Indeed, RESTful APIs are generally more focused on CRUD operations (create, read, update, delete), while OData provides a more complete set of data access and modification operations.

In addition, OData provides the ability to define custom query options and operations that can be used to add new functionality to a service without changing the underlying service implementation. REST APIs, on the other hand, typically rely on standard HTTP methods to provide functionality.

In summary, while REST APIs provide a simple, lightweight way to expose CRUD operations over HTTP, OData is a more comprehensive protocol for querying and updating data, with a rich set of features for accessing and modifying data, complex types and relationships, custom operations, and more standardized querying.


OData has some advantages over a traditional REST API. First of all, we have seen how easy and intuitive this technology is to use with Java and any other programming language allowing web exchanges. It’s so simple that you can even do it from any URL

Indeed, when you write an URL, you send information to OData which will answer in XML. Moreover, OData is often preferred because of its extensibility, which allows it to be perfectly adapted to all your needs.

Les derniers articles publiés :

What is an SoD report ?

The SoD report is a key element in the internal security audit of companies. It allows you to update, ensure

Why choose SAP ERP?

The ERP market is growing worldwide, especially in Europe. The company SAP is able to stand out with its innovative

The SoD report is a key element in the internal security audit of companies. It allows you to update, ensure and improve

The Cloud has become a must for companies. Like SAP Analytics Cloud, it allows to centralize a large amount of data in

The ERP market is growing worldwide, especially in Europe. The company SAP is able to stand out with its innovative solutions. Why

In 2027, SAP will cease promoting SAP ECC to focus on S4/HANA. Are you afraid of migrating? Yet it can bring you

Scroll to Top