Skip to Content
Technical Articles

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

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

You must be Logged on to comment or reply to a post.
  • 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….


    • 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,


      • 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,

  • 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,

      > 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,