SAP CDS APIs
CDS-based APIs expose SAP data models as services, especially OData, directly from Core Data Services views. In modern SAP, CDS is the primary way to build APIs and the data behind Fiori.
A CDS API defines the data model once as a view entity on HANA, with joins, associations and annotations, and exposes it as an OData service either through @OData.publish or, for transactional APIs, through a RAP behaviour definition and service binding. The same model then serves Fiori, analytics and external integration, which is the code-to-data and clean-core idea.
- In modern SAP, CDS is the primary way to build APIs and the data behind Fiori.
- Watch out: Bypassing CDS with hand-built services.
CDS as the API foundation
CDS views define rich, reusable data models on HANA (joins, aggregations, associations, annotations). By annotating a CDS view (or using a RAP service definition/binding), you expose it as an OData API, so the same model powers Fiori, analytics and external integration. This is the modern, low-effort path to SAP APIs.
How it works
@OData.publish: true
define view entity Z_C_SalesOrder as select from I_SalesOrder { ... }
" → generates an OData service consumable by Fiori and integrationsRAP and service binding
The ABAP RESTful Application Programming model (RAP) is the strategic framework: you define behaviour on CDS entities and bind them as OData (V2 or V4) services. This produces robust, transactional APIs for both UIs and integration, aligned with clean-core and cloud.
Why it matters
CDS-based APIs embody code-to-data and clean-core: define the model once, expose it as a service, and consume it everywhere. For modern SAP development and integration, CDS + OData (via RAP) is the standard, and a key skill.
Common pitfalls
- Bypassing CDS with hand-built services.
- Ignoring annotations that generate/shape the API.
- Not using RAP for transactional APIs.