
When building side-by-side extensions using SAP Business Technology Platform, there are two development models to choose from. The first is the SAP Cloud Application Programming Model (CAP). The other is the ABAP RESTful Application Programming Model (RAP).
A CAP application is written in an open-source language (JAVA or Python, for example) and will also run on the associated runtime (JVM in the case of JAVA, for example). RAP applications are written in ABAP, and run within the SAP Business Technology Platform ABAP Environment.
Both CAP and RAP applications allow creation of SAP HANA optimized development. Both are also based on the Core Data Services Technology (although the specifics of each differ slightly), which is a framework enabling developers to define semantically rich data models and service models based off of the OData specification. Those OData services, in turn, can be utilized when developing SAP Fiori Applications.

There is no "one-size-fits-all" approach when deciding which programming model to use. Many, if not most, scenarios can be successfully implemented using both CAP and RAP. There are a few things that as a developer you can consider when deciding which programming model to choose. Your skill set, of course, is the most obvious factor. If your specialty is JAVA or Python then it would make sense to use what you know to develop your application if your timeline does not support acquiring a new programming language. The specific types of systems in your landscape are also a factor to be considered. Finally, once specific scenarios and use cases are known, then it may advantageous to use a specific model. For example, a scenario based off custom development of an OData API where the data is coming from SAP S/4HANA Cloud may be easier to build using RAP. The important thing to remember is that each scenario stands on its own.

As mentioned previously, the ABAP RESTful Application Programming Model (RAP) defines the architecture for efficient end-to-end development of intrinsically SAP HANA-optimized OData services (such as Fiori apps). It supports the development of all types of Fiori applications as well as publishing 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.
Bringing those features into SAP Business Technology Platform now allows a fusion between ABAP and cloud native, bringing even more value to development projects. Development artifacts can both be created and managed in the cloud. End-to-end lifecycle management happens in one place. All parts of the SAP BTP ABAP Environment from the version of the ABAP Platform to the version of the SAP HANA Service will always be the latest and kept up to date. In addition, since SAP BTP ABAP Environment runs in the cloud, the operations specifics are handled by SAP, freeing developers to concentrate on more value-added tasks.

Here we see the vital parts of the SAP BTP ABAP Environment. The SAP BTP Cockpit is used to activate your ABAP service and create an instance. The development environment is centered on Eclipse with the ABAP Developer Tools plugin installed. Optionally, Git can be used for code exchange and versioning.
As mentioned earlier, the programming model used is the ABAP RESTful Application Programming Model. Along with that, a cloud-optimized ABAP language is utilized. ABAP statements that are not relevant for programming or that could potentially cause problems are prohibited. Only "released" artifacts (APIs) and keywords are permitted.
Underlying the SAP BTP ABAP Environment is an SAP HANA Service instance and, in addition, other SAP BTP services (SAP Integration Suite, SAP Launchpad Service, for example) can be utilized. The SAP BTP Connectivity Service along with the Destination Service enables secure connections for bidirectional data transfer between SAP BTP ABAP Environment applications, and both SAP and non-SAP applications.
Exploring the SAP Business Technology Platform: Scenarios for SAP BTP ABAAP Environment
Let's look at a few scenarios that utilize SAP BTP ABAP Environment.

In this scenario, a side-by-side extension can be created. The business logic of the extension (create, read, update, and delete logic) is created and runs completely within SAP BTP ABAP Environment. Any and all other SAP BTP services (analytics, machine learning, for example) are accessible for the developer to use. Data can come from both the embedded SAP HANA service instance and from other cloud applications, both SAP and non-SAP.

This second scenario is similar to the first in all respects, except notice that instead of the data coming from a cloud system, it is coming from systems that are on-premise. This requires an SSL tunnel to be established between the SAP BTP Environment and the on-premise environment. The SAP BTP Connectivity Service and SAP Cloud Connector fulfill this requirement. Once the tunnel is established insofar as SAP BTP ABAP Environment is concerned, it treats an on-premise system as no different than a cloud-based system for data retrieval.

Finally, note in this graphic the Web API located in the bottom center. One of the useful features of SAP BTP ABAP Environment is the ability to create Web APIs. A Web API is an OData service whose metadata does not entail any UI-specific annotations that are defined for the data model. It is published for the purpose of providing an API to access the service by an unspecified client. A Web API facilitates the exchange of business information between an application and any client, including from a different system or server.

Visit these links to learn more about SAP BTP ABAP Environment: