Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC 20802——开放数据协议（OData）v4.0 标准系列
Information technology — Open data protocol (OData) v4.0 — Part 1：Core & Part 2：OData JSON Format
🔗 BS ISO/IEC 20802 是英国标准协会（BSI）依据国际标准 ISO/IEC 20802 采用发布的关于开放数据协议（Open Data Protocol，OData）v4.0的信息技术标准，属于英国标准的本国实施版本（UK implementation）。OData 是一种建立在 HTTP/REST 之上的数据访问协议，用于以标准化方式完成数据资源的创建、读取、更新与删除（CRUD）以及查询，从而实现不同系统之间的数据互操作。该系列由英国技术委员会 ICT/-/1（信息系统协调）归口制定，发布时标准分类号（ICS）为 35.100.70，对应的国际标准第 1 版于 2016 年 12 月 15 日发布。系列目前收录两份标准：第 1 部分规定 OData 核心协议，第 2 部分规定 OData JSON 格式。
💡 OData 的核心思想是”让 REST API 具备结构化查询能力”：客户端仅通过 URL 即可完成筛选、排序、分页与投影（$select），无需服务端定制开发，显著降低数据集成成本，这也是其被广泛用于企业数据服务化的根本原因。
一、系列概述与定位 📌
OData 最初由微软提出并提交给 OASIS 组织标准化，OASIS 于 2014 年发布 OData v4.0 规范，随后被 ISO/IEC JTC 1（信息技术联合技术委员会）采纳为国际标准。它以统一资源标识符（URI）表达数据资源，定义了一组标准系统查询选项（如 $filter、$orderby、$top、$skip、$select、$expand、$count 等）与通用数据模型，使不同厂商、不同平台的数据库与数据服务能够被统一访问。OData v4.0 采用”协议＋格式”双层结构：协议层描述资源、操作与查询语义，格式层描述数据的序列化表示。
BS ISO/IEC 20802 系列当前收录的两个部分如下表所示。第 1 部分规定协议核心，第 2 部分规定 JSON 序列化格式，二者相辅相成，缺一不可。值得注意的是，BS 版本的英国国家序言（National foreword）指出，使用者有责任正确应用该标准，且符合英国标准并不能免除法律责任。
| 标准号 | 中文主题 | 主要内容 | 首版发布 |
|---|---|---|---|
| BS ISO/IEC 20802-1:2016 | 核心（Core） | OData v4.0 核心协议：数据模型、URI 约定、查询选项、CRUD、函数/动作与批量请求 | 2016-12-15 |
| BS ISO/IEC 20802-2:2016 | OData JSON 格式（OData JSON Format） | OData 数据的 JSON 表示、控制注释、元数据注释、错误对象与媒体资源格式 | 2016-12-15 |
⚠️ OData 是”协议＋格式”的组合：仅遵循 JSON 格式而不遵循核心协议（或反之），都无法实现完整互操作。实现方与服务端必须同时满足两个部分的要求，采购与验收时应要求厂商提供对两部分的符合性声明。
二、第 1 部分：核心协议（Core）🔧
BS ISO/IEC 20802-1 规定 OData v4.0 的核心协议，主要技术内容如下：
- 概念数据模型（CSDL）：实体类型与复杂类型、键（Key）、实体集（Entity Set）、导航属性（Navigation Property）、函数导入与操作导入等建模概念，构成服务的类型系统。
- URL 约定：服务根（Service Root）、资源路径、键段（Key Segment）、函数调用段，以及带 $ 前缀的系统查询选项。
- 协议语义：HTTP 方法映射（GET 查询、POST 创建与动作调用、PUT/PATCH 更新、DELETE 删除）、状态码、ETag 与并发控制、错误响应约定。
- 批处理（Batch）：通过多部分 MIME 封装在一次请求中提交多个原子操作，减少网络往返，支持变更集的原子性。
核心协议还定义了元数据文档（Metadata Document）的语义：服务通过 $metadata 端点暴露其类型系统，使客户端能够动态发现可用实体集、属性、导航与操作。这一”自描述”能力是 OData 区别于普通 REST API 的关键特征，也使客户端无需预先编码即可浏览任意 OData 服务。
三、系统查询选项与数据访问 📋
OData v4.0 提供了一组标准化的系统查询选项，客户端通过附加在 URL 上的查询参数控制服务器返回的数据量与形态，常用选项如下表所示：
| 查询选项 | 作用 | 典型用法示例 |
|---|---|---|
| $filter | 按条件筛选数据集 | $filter=price gt 10 and category eq ‘book’ |
| $orderby | 按一个或多个属性排序 | $orderby=name asc, age desc |
| $top / $skip | 分页：取前 N 条 / 跳过前 N 条 | $top=20&$skip=40 |
| $select | 投影：仅返回指定属性 | $select=id,name,price |
| $expand | 展开导航属性，联表返回关联实体 | $expand=orders |
| $count | 返回集合元素总数 | $count=true |
服务器应当对查询选项进行翻译与优化。筛选与展开是性能敏感的操作：$filter 中的复杂表达式应尽量下推到数据库层执行，$expand 应避免无限制的多级展开导致笛卡尔爆炸。此外，OData v4.0 还支持函数（Function）与动作（Action）：函数是只读的可调用逻辑（如标量计算或远程过程），动作是带有副作用的操作（如”下单””审核”），二者共同扩展了基于通用 CRUD 的服务能力。
⚠️ 系统查询选项在带来便利的同时也带来安全边界问题：未经授权的宽泛 $filter/$expand 可能导致敏感数据泄露或服务资源耗尽。生产环境必须在网关上实施字段级授权、查询深度限制与速率控制。
四、第 2 部分：OData JSON 格式 🔧
BS ISO/IEC 20802-2 规定 OData 数据的JSON 表示格式，这是 OData v4.0 默认的线上格式，主要内容包括：
- 数据表示：实体、实体集合、复杂属性、集合属性与导航属性的 JSON 序列化规则，键值序、类型前缀与 null 值的处理约定。
- 控制注释：以 @odata. 前缀命名的保留注释，如 @odata.context、@odata.id、@odata.type、@odata.count、@odata.nextLink 等，为响应提供上下文与分页导航信息。
- 错误格式：标准化的错误对象结构（error 对象包含 code、message，可扩展 details、target、innererror 等），保证跨实现的错误处理一致性。
- 媒体资源：媒体实体（Media Entities）与数据流属性（Stream Properties）的表示，以及二进制内容的类型声明与读取约定。
JSON 格式强调“上下文驱动的可发现性”：响应中的 @odata.context 注释指向元数据中的对应片段，@odata.id 提供实体的规范标识。客户端无需预先获取完整元数据，即可依据注释理解响应结构，实现轻量、自描述的数据交换。
💡 典型响应示例：{“@odata.context”:”…/$metadata#Products”,”value”:[{“@odata.id”:”Products(1)”,”ID”:1,”Name”:”示例产品”}]} —— @odata.context 指明集合类型，@odata.id 指明实体规范标识，其余为业务属性。
五、一致性与互操作要求 ✅
ISO/IEC 20802 对实现规定了一致性（Conformance）要求：声称符合 OData v4.0 的服务必须满足第 1 部分（核心协议）与第 2 部分（JSON 格式）的规定，包括 URL 语义、HTTP 映射、数据表示与控制注释的使用。实现可分为”仅查询”与”完整”两类符合级别，厂商应在文档中明确声明其符合级别。对于集成方而言，应要求供应商提供一致性测试结果（如借助 OASIS 社区提供的一致性测试工具），避免依赖厂商私有扩展导致锁定。
✅ 通过遵循 BS ISO/IEC 20802 的双部分结构，企业数据服务能够在协议层与格式层同时标准化，获得跨平台、跨语言的数据互操作能力，为数据中台与开放平台建设提供稳固基础。
六、工程实践与应用 🛠️
OData 广泛应用于企业数据集成、SaaS 平台开放接口、低代码平台与数据治理场景。工程实践要点包括：
- 服务端实现：可选用成熟的 OData 库（如 C# 的 OData.NET、Java 的 Apache Olingo、Node.js 的 o.js 等）构建服务，减少协议实现错误并简化查询翻译。
- 查询性能：$expand 与深层 $filter 可能引发重查询，应在服务端建立索引、限制展开深度并启用分页，防止接口退化。
- 安全控制：OData 暴露的数据面较宽，需做好身份认证、字段级权限、租户隔离与请求频率限制，必要时在网关拦截危险查询。
- 客户端互操作：使用标准客户端库按协议解析响应，优先消费控制注释而非硬编码字段顺序，避免依赖特定厂商扩展。
- 演进与版本：通过 $metadata 与注释实现版本演进，向后兼容的属性增补应避免破坏现有客户端的解析。
七、常见问题解答 ❓
❓ 问：OData 与普通 REST API 有什么区别？
答：OData 是 REST 之上的一套标准化协议，定义了数据模型、统一查询语法、标准格式与注释约定；普通 REST API 通常为每个服务定制，缺少通用查询与互操作能力。按 OData 实现的服务天然具备”自描述”与”可浏览”特性。
答：OData 是 REST 之上的一套标准化协议，定义了数据模型、统一查询语法、标准格式与注释约定；普通 REST API 通常为每个服务定制，缺少通用查询与互操作能力。按 OData 实现的服务天然具备”自描述”与”可浏览”特性。
❓ 问：第 1 部分与第 2 部分如何分工？
答：第 1 部分规定协议核心（资源、操作与查询语义），第 2 部分规定数据的 JSON 序列化格式与控制注释，二者结合构成完整的 OData v4.0 规范；符合性要求同时指向两个部分。
答：第 1 部分规定协议核心（资源、操作与查询语义），第 2 部分规定数据的 JSON 序列化格式与控制注释，二者结合构成完整的 OData v4.0 规范；符合性要求同时指向两个部分。
❓ 问：$select 与 $expand 有什么作用？
答：$select 用于选择返回字段（投影），$expand 用于展开关联导航属性（联表），两者共同减少网络传输并提升客户端开发效率，但 $expand 使用不当会带来性能风险。
答：$select 用于选择返回字段（投影），$expand 用于展开关联导航属性（联表），两者共同减少网络传输并提升客户端开发效率，但 $expand 使用不当会带来性能风险。
🔍 问：采用 OData 时最大的工程风险是什么？
答：通常来自”开放性”带来的安全与性能风险——未授权的宽泛查询、深层 $expand 导致的服务压力等，需要在网关与数据层做好防护与限制，并对公开服务做充分的压测。
答：通常来自”开放性”带来的安全与性能风险——未授权的宽泛查询、深层 $expand 导致的服务压力等，需要在网关与数据层做好防护与限制，并对公开服务做充分的压测。
📌 问：如何验证一个 OData 服务是否符合 BS ISO/IEC 20802？
答：应要求供应商提供符合性声明与一致性测试结果，确认核心协议与 JSON 格式两部分均满足要求；不建议仅凭”支持 $filter”等个别特性判断符合性。
答：应要求供应商提供符合性声明与一致性测试结果，确认核心协议与 JSON 格式两部分均满足要求；不建议仅凭”支持 $filter”等个别特性判断符合性。
