Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
RalfHandl
Product and Topic Expert
Product and Topic Expert
Seven years ago we published OData 4.0 as a set of OASIS Standards - now we have the next incremental, fully compatible "release": the OData 4.01 specifications – Core, JSON Data, JSON Metadata, and XML Metadata – are approved as OASIS Standards and have been published.

OData 4.01 Core (Protocol & URL Conventions) is a fully compatible set of extensions to OData 4.0, containing

OData JSON Format 4.01 is a fully compatible set of extensions to the data format, most prominent extensions are

OData CSDL ($metadata) JSON 4.01

  • JSON representation of $metadata – no XML needed any more ?


OData CSDL ($metadata) XML 4.01

  • Improved annotation language for UI use cases


See What’s New in OData Version 4.01 for a complete list of changes.

So what’s next?

Please forward this info to whom it may concern.

Thanks for your feedback and support!
Ralf Handl
6 Comments
hardyp180
Active Contributor
That's great.

All we need now is SAP support for that ODATA V4.0 standard that was announced seven years ago! Even ABAP in the Cloud still defaults to ODATA V2.0....

 
0 Kudos
I wonder about the relationship between OData and CAP. The latter certainly builds on OData principles, and it adds flexibility and elegance via aspects and projections. But can we be given a coherent picture of their alignment, of what the two share and where they differ, in how far CAP is like an extension or like an alternative to OData? As a starting point I suggest the deliberately naive question: why CAP if we have OData?
david_kunz2
Advisor
Advisor


Hi Hans-Juergen Rennau,
> why CAP if we have OData?

These are totally complementary things. CAP uses OData as a protocol to talk with other services (or with a UI) similar to the use of SQL as a protocol to talk to a database.

Best regards,
David

0 Kudos
Many thanks, David, for responding! I have difficulties, though, to align your statement with my impressions. Isn't CAP built upon an entity data model? OData I regard as "Entity data model + REST". And isn't the entity data model of OData a direct template for the data model of CAP:

  • OData data services -> CDS service

  • entity -> entity

  • key -> key

  • property -> element

  • navigation property -> association

  • containment navigation property -> composition)

  • complex type -> complex type

  • type -> type

  • enumeration -> enumeration

  • annotation -> annotation


The CAP web site states: "It [CDS] serves as our ubiquitous modeling language, for example, for capturing domain models and service definitions in a conceptual way, and as such is the very backbone of CAP."

Capturing domain models and service definitions is done with CDL, and CDL (semantics, not syntax) looks to me like "OData + elegance (script language, projections) + flexibility (aspects)".

David, would you disagree with that summary of CDS? If not, are CAP and OData really completely orthogonal? OData's formula "Entity data model + REST" is less than CAP, but what is CAP's formula? Would "Entity data model + ?" be appropriate, if so, what is the "?"?

Please correct me if I am misconceiving things.

Kind regards,

Hans-Jürgen
david_kunz2
Advisor
Advisor
Hello Hans-Juergen,

It's complementary because:

a) You don't need CDS to build an OData service.
b) You don't need OData to expose a CDS model.

CDS is a _ubiquitous_ modelling language. You don't necessarily have to build an OData service, e.g. it would be perfectly fine to build a GraphQL service. CDS is independent of the protocol.

Best regards,
David
StephanHeinberg
Participant
0 Kudos
Now that ABAP platforms supports odata 4.0 with CDS and RAP, are there plans, when odata 4.01 will be supported?

Thanks,

Stephan