Restful ABAP Programming(简称 RAP)旨在找到 SPA 和 MPA 之间的 最佳平衡点。
RAP 丰盛了 JSON 自身或初始 OData 申请的元数据中的响应，并且视图和模型是先前在 CDS 中定义的后盾 annotation：
这种办法也导致了一种相似于 HDA 的前端薄、后端强的架构。然而，RAP 旨在以有组织和受控的形式实现这一指标：每个 API 都基于 OData 协定，视图应用 UI 正文定义，数据模型在 DDL 中定义，模型更新在 RAP 类的本地实现中开发，并且所有内容都别离分层，由虚构数据模型进行编排。最初，这种办法确保了高度组织化的开发过程，在大多数应用状况下都十分无效。
然而，RAP 不反对应用 RTTI 进行模型更改，并且通过扩大视图很快超出了后端正文的性能范畴，因而须要应用 Fiori Elements 开发应用程序（还须要额定的部署）。
首先，咱们不定义一个特定的 HTTP 服务来传输视图和数据。相同，每个应用程序都应用雷同的通用 HTTP 处理程序，包含两个字符串（一个用于视图，一个用于数据），打消了开发独自的 SEGW 或 CDS OData 服务的须要。在运行时，ABAP 变量和表格被转换为 JSON 模型，并作为字符串传输到前端。在 JavaScript 中，它被解析为 JSON 模型，并绑定到 UI5 视图中：
此外，咱们不仅发送数据，还随每个申请发送元数据（数据模型），这与经典的 OData 通信不同，在经典的 OData 通信中，元数据在开始时与初始 OData 申请一起发送以建设模型，之后仅替换数据。通过这种办法，咱们当初能够针对每个申请发送不同的模型：