打开一个 SAP Fiori 应用，进入销售订单列表，界面背后很可能正在发送类似GET /SalesOrder的请求。点击某张订单进入 Object Page，前端可能继续读取订单项目、业务伙伴、状态等关联数据。修改交货日期并保存时，请求又会变成PATCH。创建新的业务对象时，则很容易看到POST。从浏览器这一端看，不过是几次 HTTP 请求。但沿着请求继续往 SAP 后端走，会经过 SAP Gateway、OData 协议层、业务服务、ABAP Runtime、CDS 数据模型，现代 ABAP Cloud 场景下还可能进入 RAP Runtime Engine。最终，前端界面上的一次点击会转化成对 SAP 业务对象的一次读取、创建、修改或者删除操作。理解这条链路，是理解 SAP Gateway 的一个非常好的入口。SAP 官方在当前 SAP Gateway Foundation 2025 FPS01 文档中仍然明确说明，REST 是 SAP Gateway 的基础架构原则之一，而 SAP Gateway 通过基于 REST 的 OData 服务，将 SAP 业务能力暴露给不同设备、技术和平台。REST 这个词已经被使用了二十多年，但它经常被简化成一种错误认识，也就是 REST 等于 HTTP 加 JSON。实际上远没有这么简单。REST 全称为Representational State Transfer，中文通常翻译成表述性状态转移或者表现层状态转移。这个名字来自 Roy Fielding 在 2000 年发表的博士论文。RES