在 SAP S/4HANA 项目里做一个 OData 服务，真正困难的地方往往不是把数据从 ABAP 内表送到 HTTP Response。SEGW 可以生成代码，RAP 可以通过 Service Definition 和 Service Binding 暴露服务，CAP 也能很快把 CDS 模型发布成 OData。真正拉开服务质量差距的，是模型到底有没有按照 REST 和 OData 的思路设计。这件事在项目后期尤其明显。一个服务刚上线时，前端只需要显示一个列表，后端返回几十条数据，看起来几乎什么设计都能工作。过了一段时间，SAPUI5 页面开始增加筛选、排序、分页、Object Page、附件、导航、批处理，外部系统也开始消费同一个 API。此时早期模型中的问题会一起浮出水面。原本只需要一次请求的页面变成十几个请求，本该通过$filter完成的查询变成自定义 Function Import，本该是数值的金额被设计成字符串，附件又被塞进普通属性里，前端不得不写大量特殊逻辑。SAP Gateway 官方文档一直强调 REST 是 SAP Gateway 的基础架构原则之一，服务应遵守客户端服务器、无状态、可缓存、分层系统和统一接口等 REST 原则。SAP Gateway 通过 OData 把 SAP 业务数据暴露给不同设备和平台，而不是把传统 ABAP Function Module 简单包装成 HTTP 接口。这正是理解 OData Best Practices 的入口。少设计动作，多设计资源很多有传统 RFC 或 Web Service 开发经验的 ABAP 开发人员，在设计 OData 服务时很容易沿用 RP