RESTful 애플리케이션 프로그래밍이라는 뜻이다.
이때 RESTful은 REST라는 웹 아키텍처 원칙을 따르는 API 스타일을 말한다.
보통 아래와 같은 특징들을 가진다.
| HTTP Method | 의미 | 예시 |
|---|---|---|
| GET | 조회 | GET /SalesOrder |
| POST | 생성 | POST /SalesOrder |
| PATCH | 수정 | PATCH /SalesOrder(4711) |
| DELETE | 삭제 | DELETE /SalesOrder(4711) |
SAP는 이제 ABAP UI = GUI가 아니라
ABAP UI = Fiori(App) + Web 형태로 전환을 하려고 한다. 따라서 SAP 데이터는 아래와 같은 방식으로 제공되어야 한다.
따라서 RAP는 SAP가 선택한 현대 표준 프로토콜인 OData v4를 기본으로 한다. 이때 Odata v4라는 것은 완전한 RESTful 형식을 따르는 SAP 표준 API 방식이다.즉 SAP 데이터가 웹, 앱, 클라우드에서 동일하게 접근이 가능하다는 말이 된다.
SAP RAP는 SAP BTP, ABAP 환경 또는 ABAP 애플리케이션 서버에서 Odata 서비스를 개발하기 위한 SAP의 권장 프로그래밍 모델이다.
원래 SAP ABAP 개발 환경은 GUI 시반 모듈풀 프로그램 중심이었다. 따라서 과거에는 UI와 비즈니스 로직이 강하게 결합된 구조를 가지고 있었다.
SAP GUI
모듈풀 (스크린 프로그램)
Dynpro 화면
PBO/PAI 이벤트
하지만 클라우드와 웹 시대가 오면서 Fiori(UI5)가 등장했다.
SAP는 모바일, 웹 시대 대응을 위해 아래와 같은 기술들을 차용하기 시작했다.
SAPUI5
Fiori Design
Odata 서비스 구조
이제 개발자들은 UI5로 프론트를 만들고 백엔드는 SEGW(게이트웨이)로 Odata를 만들어 연결했다. 하지만 이 방식은 CRUD를 모두 따로 메서드를 만들어야 하는 번거로움이 있었다. 그래서 RAP를 이용해서 자동으로 CRUD를 개발자가 만들지 않아도 될 수 있게 해놓은 것이다.
단, CRUD가 복잡해서 RAP를 만들었다기 보단 아래 핵심 4가지 이유가 존재한다.
이 방식들은 기존 ABAP 방식으로는 SAP BTP/CLOUD에 맞출 수가 없었다.
기존 ABAP 같은 경우는 UI + 로직 + DB가 섞여 있었는데 RAP에서는 완벽하게 분리된 구조를 강제한다.
CDS : 데이터
Behavior : 로직
Odata : 서비스
UI : Fiori/UI5
게이트웨이는 Odata v2까지만 지원한다. SAP는 미래 표준을 Odata V4로 결정했기 때문에 새로운 프레임워크가 필요했다.
따라서 SAP RAP는 Fiori App 개발의 표준이라고 SAP가 선언을 하였다. 즉, 곧 모든 SAP 신규 앱은 RAP 기반으로 만들어질 예정이라고 생각한다.