The ABAP RESTful Application Programming Model defines the architecture for end-to-end development of OData services (such as SAP Fiori apps) in the ABAP environment. It supports the development of all types of Fiori applications and the publishing of Web APIs. It is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating OData services with bindings to an OData protocol and ABAP-based application services for custom logic and SAPUI5-based user interfaces.
In this unit, you will create a Sustainable Grocery Application using an ABAP RESTful Application. The required objects for an ABAP RESTful Application include:
- Database Tables
- Core Data Service (CDS) Entities
- Core Data Service (CDS) Behavior Definitions
- Core Data Service (CDS) Metadata Extensions
- A Service Definition
- A Service Binding

Developing a RAP application consists of the following main steps:
- Provide the Database Tables
- Developing a RESTful Application starts with providing the database tables. Depending on the development scenario, these can be existing tables, legacy tables, or tables created specifically for this application.
- Define the Data Model.
- The data model of the Business Object is defined with Core Data Service (CDS) Views. Depending on whether it is a simple or a composite Business Object, one or more CDS Views are required. In the case of a composite Business Object, this is also the place where you define the entity hierarchy.
- Define and Implement the Behavior (Transactional apps only)
- The behavior of a RESTful Application Business Object is defined in a repository object called Core Data Service (CDS) Behavior Definition. Usually, the behavior of a RESTful Application Programming Business Object also requires some additional logic implemented in a certain type of global ABAP class called a Behavior Pool. For a non-transactional application, for example, a list report, the behavior definition or implementation can be omitted.
- Project the RESTful Application Programming Business Object and provide service-specific Metadata
- The RESTful Application Programming Business Object projection consists of a data model projection and, if a behavior has been defined, a behavior projection. To define a projection, you create one or more Core Data Service (CDS) projection views, which is a type of CDS View, and a Behavior Projection, which is a type of behavior definition. For User Interface (UI) services, the projection view(s) should be enriched with UI-specific metadata. To support the future extensibility of the application, we recommend placing the service-specific annotations in metadata extensions.
- Define the Service
- In RESTful Applications, a service is defined by creating a Service Definition. The service definition references the projection views and specifies what should be exposed, that is, what is visible to the service consumer.
- Bind the Service and Test the Service
- A service binding is needed to specify how the service should be consumed (UI or Web API) and via which protocol (OData V2 or OData V4). For UI services, a Preview is available.