Introducing the OData protocol

Open Data Protocol (OData) is an OASIS standard that defines the best practice for building and consuming RESTful APIs. OData helps you to 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, query options, and so on. It is an open standard that is defined by the OASIS consortium.

OData also guides you in tracking changes, defining functions or actions for reusable procedures, sending asynchronous or batch requests, and so on. Additionally, OData provides a facility for extension to fulfill any custom needs of your RESTful APIs.

OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools. Some of these can help you interact with OData, even without knowing anything about the protocol.

One of the main features of OData is that it uses the existing HTTP verbs GET, PUT, POST, and DELETE against addressable resources identified in the URI. Conceptually, OData is a way of performing database-style create, read, update, and delete operations on resources by using HTTP verbs:

OData currently supports two formats for representing the resources it exposes:

• The XML-based AtomPub
• The JSON formats

JSON has significantly less protocol overhead than the Atom Publishing protocol. JSON can easily be consumed with JavaScript and by SAPUI5.

Each OData service is represented by a URI, called the service root URI. A URI (Uniform Resource Identifier) is a uniform resource identifier, which is a string of characters used to identify a resource. More precisely, each resource can be accessed using a URL (Uniform Resource Locator), a uniform resource locator, describing how to access the resource. This type of identification enables interaction with representations of the resource across a network using specific protocols like OData.

The service document lists entity sets, functions, and singletons that can be retrieved. Clients can use the service document to navigate the model in a hypermedia-driven fashion. The service document is available at http://<host>:<port>/<service>/.

The metadata document describes the types, sets, functions, and actions understood by the OData service. Clients can use the metadata document to understand how to query and interact with entities in the service. The service metadata document is available at http://<host>:<port>/<service>/$metadata. The URL will return XML metadata of the service (Entity data model). The response of a service metadata document only supports XML.

In a CAP-based application, services are usually articulated through Core Data Services (CDS) models and are managed by the CAP runtime environment. In the CAP framework, every functional component is viewed as a service. These services represent the interactive characteristics of a domain, including the entities they expose, the actions they enable, and the events they trigger.

You now have a more profound understanding of the OData protocol and you can describe its key concept. You also learned about OData in CAP and have heard about the possibility to use different protocols through protocol adapters.

• OData - the Best Way to REST
• Understand OData in 6 steps
• Providing Services in CAP
• Protocol Adapters