What is OData and what is it used for in industry?

OData stands for “Open Data Protocol”. It describes how data services are built in the REST style: clients read and change resources using ordinary HTTP messages, resources are addressed by URLs, and a data model describes which objects and properties exist. That is how the OASIS OData specification puts it.

The practical gain lies in uniformity. If you know one OData service, you can use the query logic of a second one without learning anything new. The table compares OData with a custom-built interface.

The idea of shared data access is older than the standard. In May 2012, Microsoft, IBM and others proposed an OData technical committee at the standards body OASIS, and Microsoft contributed seven specification components. OASIS approved OData 4.0 as a standard on 24 February 2014, and in 2016 it was accepted as ISO/IEC 20802. OData 4.01 followed on 23 April 2020.

A back-of-the-envelope calculation shows why this matters for connections. Purely as an illustration: six systems that each talk to one another individually need up to 6 × 5 / 2 = 15 connections. If all six speak the same standard through a shared layer, it is six connections. The figures are a worked example, not a measurement from a project.

OData is not a single document but a family of specifications. The overview lists the parts used most often in practice.

Four mechanisms carry the standard.

• Addressing: A set sits behind the service path, for example Products. A single record is addressed by its key in parentheses, for example Products(1).
• Query options: $filter narrows records, $select chooses properties, $expand includes related data, and $orderby, $top and $skip sort and page.
• Write access: Records are created with POST, changed with PATCH or PUT and removed with DELETE. ETags protect against overwriting when two users change a record at the same time.
• Metadata and batch: The service document lists the available sets, and $metadata describes the model. Batch requests bundle several operations into one call.

The sequence is similar for most connections.

1. Clarify the data model

   Which objects do you need, such as orders, materials or sites, and which properties are required for that?

2. Check the service

   Retrieve the service document and $metadata. They show which sets and fields the service actually offers.

3. Define queries and access

   Define filters and fields so that only the necessary data is transferred, and clarify authentication and permissions.

4. Operate and maintain

   Monitor response times and errors, and allow for the fact that the service’s model can change.

Four distinctions prevent common misunderstandings.

• Not a machine protocol: OData talks to data services, not directly to a controller. Protocols such as OPC UA or Modbus exist for that.
• Not a data stream: OData works with request and response over HTTP. For events a sender distributes continuously, protocols such as MQTT are a better fit.
• Not a database: OData describes access, not storage. Any data store can sit behind it.
• Not just any REST: OData adds fixed rules for model, queries and errors to REST. An arbitrary JSON service is therefore not yet an OData service.

The hurdles rarely lie in the protocol, but in what is provided behind it.

• Services in different OData versions that a client has to handle separately
• Queries that are too broad, such as $expand across many relationships, which raise response times
• Unclear permissions: who may read or change which sets?
• Fields with the same name but different meaning in different systems

For pronubes, OData is one possible way into source and target systems. The product parts take on different tasks.

• pronubes Edge: Edge connects machines, plants and target systems without a separate interface project for each link. Systems with a standardized interface are particularly well suited.
• pronubes Zones: Zones maps sites, production areas, systems and data flows in a clear structure. This helps assign data from an OData service unambiguously to the right site and area.
• pronubes Insights: Insights shows whether connections and data flows run stably in live operation. You see early when a service responds slowly or returns errors.