OData Version 4.01 published as OASIS Standards
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
- Mass operations for A2A use cases, e.g. array upsert
- Alignment with REST API best practices, e.g. key-as-segment
- Alternate keys: useful for our Domain Model Alignment
OData JSON Format 4.01 is a fully compatible set of extensions to the data format, most prominent extensions are
- JSON Batch format – no more complicated multipart/mixed format – already implemented by our SAP Cloud Application Programming Model for Node.js
- Simplified delta format: useful for our Mobile Offline clients
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?
- A new iteration of the Extension for Data Aggregation is planned for this year
- Additions to the Standard Vocabularies which form the basis for our SAP Vocabularies extensively used by SAP Fiori Elements
- An Extension for Temporal Data, useful for our Domain Model Alignment
Please forward this info to whom it may concern.
Thanks for your feedback and support!
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....
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:
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.
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.
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?
Hi Hans-Juergen Rennau,
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.
Now that ABAP platforms supports odata 4.0 with CDS and RAP, are there plans, when odata 4.01 will be supported?