Whats the ODATA and REST API’s and why we need that?
Combination of different software system is sometimes need, sometimes mandatory in our modern IT world. The question is that how these systems have to communicate and exchange Datas. A number of standards and protocols have been discovered to facilitate communication between different systems. If you have ever explored these systems, you might have come across two popular technologies: OData and REST APIs.
What's an REST?
An API is a set of definitions and protocols for building and integrating application software. It’s sometimes referred to as a contract between an information provider and an information user—establishing the content required from the consumer (the call) and the content required by the producer (the response). For example, the API design for a weather service could specify that the user supply a zip code and that the producer reply with a 2-part answer, the first being the high temperature, and the second being the low.
REST (REpresentational State Transfer) is a software architectural style that defines how to send messages between two different systems using the HTTP protocol. Originally developed by Roy Fielding two decades ago, REST has grown to become the most popular architecture for exchanging information on the World Wide Web.
The REST standard outlines 6 different principles or architectural constraints for web services. But i will not write about that because our subject is different.
What's an ODATA?
ODATA identifies itself „OData (Open Data Protocol) is an OASIS standard that defines the best practice for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats and query options etc. OData also guides you about tracking changes, defining functions/actions for reusable procedures and sending asynchronous/batch requests etc. Additionally, OData provides facility for extension to fulfil any custom needs of your RESTful APIs.“
OData vs REST: What’s the Difference?
REST is an architectural style for exchanging information via the HTTP protocol. The REST standard defines principles that must be adhered to by any REST API.
OData builds on top of the REST framework to define best practices for building REST APIs—including the HTTP message format, how to query the API, and more. Although OData encourages users to follow REST principles at all times, this requirement can be relaxed if there is a compelling reason. In addition, OData specifies that data should be transferred in Atom or JSON format.
If we summarize
REST is a generic design technique used to describe how a web service can be accessed. Using REST you can make http requests to get data. If you try it in your browser it would be just like going to a website except instead of returning a web page you would get back XML. Some services will also return data in JSON format which is easier to use with Javascript.
OData is a specific technology that exposes data through REST.
REST - design pattern
OData - enabling technology
You can better runderstand ODATA Technology with this tutorial:
https://www.odata.org/getting-started/understand-odata-in-6-steps/
WHAT ist he advantages of ODATA?
OData provides the following benefits:
- It lets developers interact with data by using RESTful web services.
- It provides a simple and uniform way to share data in a discoverable manner.
- It enables broad integration across products.
- It enables integration by using the HTTP protocol stack.
What is new ODATAV4?
Model improvements.OData V4.01 services can support the following new metadata constructs:
- Edm.Untyped – For specifying that a property may be any type. Supports representing things outside of the OData data model, such as variant typed properties, mixed collections, or collections of collections.
- Keyless entity types for Singletons – entity types used as singletons, or singleton navigation properties, no longer need to have a defined key value
- Specialization in Derived Types – Derived types can restrict properties of a base type to be a subtype of the property’s declared type.
- Ordered Collections – Services can annotate a collection as being “Ordered”, and syntax is added for referencing a member of an ordered collection of primitive or complex types for the purposes of retrieval, update, or delete, as well as inserting into a given location within an ordered collection.
- Optional Function Parameters – Function parameters can be annotated as optional. Optional parameters may be omitted when invoking the function.
Simplified URL patterns.OData V4.01 adds support for simplified URL syntax, including:
- Key as Segment – Common semantics for representing keys within a URL as a segment, rather than enclosed in parenthesis.
- Query Option Simplification – Query options are now case-insensitive, and can optionally omit the $ prefix.
- Optional type prefix for Enums, Durations – Enum and duration values in a Url can be specified without the type prefix.
- Simplified Operations – Operation names are now case-insensitive, and namespace qualification is optional.
New Query Features.OData V4.01 adds support for new query functionality, including:
- Computed Properties – Support for projecting computed properties
- Set Operations – Support for updating/deleting/invoking actions on resources matching a particular criteria
- New “in” operator – Expressions containing many OR statements can be simplified with the new “in” operator
- Filtered Count – $count can be computed on a filtered nested collection
- In-lined stream properties – Stream properties can be requested inline within a payload
- Delta Update Payloads – Delta payloads can now be used in updates to submit a set of changes, including nested changes, to a collection
Simplified OData JSON Payloads.OData V4.01 simplifies JSON payloads to look more like custom payloads, including:
- Optional OData Prefix – OData Prefix may be omitted from control information
- Default Namespaces – Services can declare default namespaces in order to omit namespace prefixes from instance annotations
- Optionally Omit Null Values – Clients can specify a preference to reduce payload size by omitting null or default values.
- Improved Async response message – In OData V4.0, completed async responses were wrapped as an application/http response message. In 4.01, clients can request async responses be returned unwrapped.
- New delta payload representation – OData V4.01 introduces a simplified representation for delta payloads, including nested delta sets.
A JSON representation for CSDL Metadata.OData V4.01 defines a new JSON representation for CSDL Metadata.
A JSON representation for Batch payloads.OData V4.01 defines a new JSON representation for batch request and response payloads.
SUMMARY:
ODATAv4 consider so much new things. I think ist better to use V4 instead of V2. Because it has better performance, improved data types, better filter, sort, expand functions, nested parameters, better data modification property, Addressing References, useful Query Options, new parameters etc.
References
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/odata
https://blogs.sap.com/2016/02/08/odata-everything-that-you-need-to-know-part-1/
http://docs.oasis-open.org/odata/new-in-odata/v4.0/cn01/new-in-odata-v4.0-cn01.pdf
https://openui5.hana.ondemand.com/#/topic/abd4d7c7548d4c29ab8364d3904a6d74
https://blogs.sap.com/2021/02/05/is-it-time-to-switch-to-odata-v4/
https://help.sap.com/docs/ABAP_PLATFORM/468a97775123488ab3345a0c48cadd8f/abd4d7c7548d4c29ab8364d3904...
