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 请求一起发送以建立模型，之后仅交换数据。 通过这种方法，我们现在可以针对每个请求发送不同的模型：
