Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC 20802 — Open Data Protocol (OData) v4.0 Standard Series
Information technology — Open data protocol (OData) v4.0 — Part 1 & Part 2
🔗 BS ISO/IEC 20802 is the British Standards Institution (BSI) adoption of the ISO/IEC 20802 series, covering the Open Data Protocol (OData) v4.0. OData is a data-access protocol built on HTTP/REST that provides a standardised way to create, read, update, and delete (CRUD) and to query data resources, enabling data interoperability across systems. It was prepared by UK technical committee ICT/-/1 (Information Systems Co-ordination) and carries ICS classification 35.100.70. The series currently comprises two parts: Part 1 specifies the OData core protocol and Part 2 specifies the OData JSON format.
💡 The core idea of OData is to “give REST APIs structured query capability”: a client can perform filtering, sorting, paging, and projection (select) purely through the URL, without custom server-side development, significantly reducing data-integration cost.
1. Series Overview and Positioning 📌
OData was originally proposed by Microsoft and submitted to OASIS for standardisation, and later adopted as an international standard by ISO/IEC JTC 1. It expresses resources with uniform resource identifiers (URIs), defines a set of standard query options (such as $filter, $orderby, $top, $select, $expand, etc.) and a common data model, so that data services from different vendors and platforms can be accessed uniformly.
The two parts currently in the BS ISO/IEC 20802 series are shown below. Part 1 specifies the protocol core and Part 2 specifies the JSON serialisation format.
| Standard | Subject | Key Content | Edition |
|---|---|---|---|
| BS ISO/IEC 20802-1:2016 | Core | OData v4.0 core protocol: data model, URIs, query options, CRUD, and operations | First edition 2016-12-15 |
| BS ISO/IEC 20802-2:2016 | OData JSON Format | JSON representation of OData data, metadata annotations, and the error-object format | First edition 2016-12-15 |
⚠️ OData is a combination of “protocol + format”: following only the JSON format without the core protocol (or vice versa) cannot achieve full interoperability. Implementations and servers must satisfy both parts.
2. The OData Core Protocol 🔧
BS ISO/IEC 20802-1 specifies the core protocol of OData v4.0, whose main content includes:
- Data model: concepts such as entity types, complex types, entity sets, navigation properties, and keys.
- URL conventions: service root, resource paths, query options, and system query options ($filter, $orderby, $top, $skip, $select, $expand, $count, etc.).
- Operations: CRUD, functions and actions, batch requests, etc.
- Protocol semantics: HTTP method mapping (GET/POST/PUT/PATCH/DELETE), status codes, and error handling.
3. The OData JSON Format 🔧
BS ISO/IEC 20802-2 specifies the JSON representation format of OData data, including:
- Data representation: JSON serialisation rules for entities, collections, associations, and navigation properties.
- Metadata annotations: the semantics and usage of control annotations such as @odata.id and @odata.context.
- Error format: the standardised error-object structure (code, message, target, details).
- Media and streams: conventions for handling media resources and binary streams.
💡 The OData JSON format emphasises “context-driven discoverability”: through @odata.context and @odata.id annotations, a client can understand the response without knowing the service metadata in advance, achieving self-describing API responses.
4. Engineering Practice and Applications 🔍
OData is widely used in enterprise data integration, open interfaces of SaaS platforms, and data-as-a-service. Engineering practice points include:
- Server-side implementation: use mature OData libraries (such as OData.NET or Apache Olingo) to build services and reduce protocol-implementation errors.
- Query performance: $expand and $filter can trigger deep queries; translate queries and optimise indexes on the server and guard against abuse causing performance issues.
- Security controls: OData exposes a broad data surface, so authentication, field-level permissions, and request-rate limiting must be implemented carefully.
- Client interoperability: use standard client libraries to parse responses per the protocol, avoiding dependence on vendor-specific extensions.
5. Frequently Asked Questions ❓
❓ Q: What is the difference between OData and an ordinary REST API?
A: OData is a standardised protocol on top of REST, defining a data model, a unified query syntax, and a standard format; an ordinary REST API is usually customised per service and lacks generic query and interoperability capabilities.
A: OData is a standardised protocol on top of REST, defining a data model, a unified query syntax, and a standard format; an ordinary REST API is usually customised per service and lacks generic query and interoperability capabilities.
❓ Q: How do Part 1 and Part 2 divide the work?
A: Part 1 specifies the protocol core (resources, operations, and query semantics), while Part 2 specifies the JSON serialisation format and annotations; together they form the complete OData v4.0 specification.
A: Part 1 specifies the protocol core (resources, operations, and query semantics), while Part 2 specifies the JSON serialisation format and annotations; together they form the complete OData v4.0 specification.
❓ Q: What do the $select and $expand query options do?
A: $select chooses which fields to return (projection), and $expand unfolds related navigation properties (joins); together they reduce network transfer and improve client development efficiency.
A: $select chooses which fields to return (projection), and $expand unfolds related navigation properties (joins); together they reduce network transfer and improve client development efficiency.
🔍 Q: What is the biggest engineering risk when adopting OData?
A: It usually comes from the security and performance risks of “openness” — unauthorised broad queries and deep $expand causing server load — so protection and limits are needed at the gateway and data layers.
A: It usually comes from the security and performance risks of “openness” — unauthorised broad queries and deep $expand causing server load — so protection and limits are needed at the gateway and data layers.