在 SAP Gateway 开发现场，最容易出现的一类误判，是看到/IWFND/GW_CLIENT返回 HTTP 200，就认为一个 OData 服务已经开发完成。从协议层面看，请求确实成功了。从消费者视角看，情况可能完全不同。$metadata里充斥VBELN、KUNNR、MATNR这样的底层字段名，所有属性都被定义成Edm.String，Entity Set 名称与 Entity Type 混在一起，货币金额没有 Currency 关联，重量没有 Unit 关联，错误响应直接把后端异常文本扔给前端，甚至一个 GET 请求在读取数据的同时悄悄修改了业务对象。这样的服务能运行，却很难称得上高质量 API。SAP Gateway Foundation 本身承担的正是 SAP 业务数据与各种消费端之间的 OData 连接角色。SAP 当前的 Gateway 文档仍然保留了针对高质量 OData Service 的完整设计主题，同时 Service Builder 继续提供数据模型创建、导入、生成和服务实现能力。真正成熟的 OData 服务，需要同时处理三件事。元数据要让消费者看得懂，运行时行为要符合 HTTP 与 OData 的契约，Gateway 实现还要避免把后端技术结构直接暴露成公共 API。这三件事缺少任何一件，服务都容易从企业 API 退化成远程调用接口。一个好的 OData 模型，不应该长得像数据库表的远程投影很多经典 S