在/IWFND/GW_CLIENT里测试一个 SAP Gateway OData 服务时，经常会碰到一种很有迷惑性的情况。HTTP 请求能够成功返回200 OK，JSON 数据也能正常解析，SAP UI5 页面甚至已经能够显示业务数据，但从 API 设计角度审视，这个服务依然可能存在非常严重的问题。问题通常不在 ABAP 代码能不能跑，而在于我们究竟有没有真正按照 OData 的方式建模。很多 SAP 项目里的 OData 服务，是由熟悉 RFC、BAPI、SOAP Web Service 或传统接口开发的 ABAP 开发人员设计出来的。开发经验当然可以复用，但如果把原来的 RPC 思维直接套到 OData 上，很容易做出一种看起来像 OData、实际上只是披着 OData 外壳的远程调用接口。SAP Gateway 官方的 OData Best Practices 一直强调一件事，OData 不只是把数据库查询结果转换成 JSON，也不是简单地把一个 ABAP Function Module 暴露成 HTTP Endpoint。OData 提供的是一套围绕资源、实体模型、关系、导航、查询和元数据建立起来的统一协议。当前 OData 4.01 规范仍然明确把遵循 REST 原则、保持简单、允许扩展以及通过统一方式描述数据与数据模型列为核心设计思想。把这个认识建立起来之后，下面 8 条 OData 设计禁忌就很好理解了。不要用 SOAP 的思维设计 OData这一条排在所有问题前面，因为后面很多反模式，其实都是 SOAP 思维残留下来的结果。SOAP 服务常见的
