在实际的 SAP Gateway 项目里，经常会出现这样一个场景。一个ProductsEntitySet 已经能够正常返回产品数据，SAP Fiori 或 SAP UI5 前端开始接入以后，很快就会提出更细的读取要求。有的页面只需要产品名称和类别，有的页面需要同时显示供应商以及供应商下面的产品，有的页面只关心记录数量，还有的调用方甚至不需要完整的 OData JSON，而只想拿到某个字段最原始的值。如果每一种读取方式都要求 ABAP 开发人员重新增加一个方法、重新定义一个接口，OData 很快就会退化成传统 RPC 风格接口集合。OData 的设计思路刚好相反，资源模型保持稳定，客户端通过标准化 URI 对资源的返回形态进行描述。SAP Gateway Foundation 对其中一部分 Query Options 提供框架级支持，因此很多能力并不要求我们在 DPC_EXT 中专门写一段 ABAP 代码去解析 URL。SAP 官方的 SAP Gateway 文档将相关能力划分为框架自动可用以及需要应用实现参与的不同类别，其中经典 Gateway 文档明确把$select、$count、$expand、$format、读取$links以及$value放在不需要额外实现的框架能力中。这里的 No Additional Implementation Needed 很容易产生误解。它并不是说开发一个 OData Service 完全不需要 ABAP 代码，也不是说数据库访问已经天然达到最佳性能，更不是说 SAP Gateway 会