OData Fundamentals

We are following the REST architecture design paradigm in the sense that the protocol transfers representations of the state of resources. In this course, the term resource denotes data that is addressable and accessible. The standard address representation or resource is the Uniform Resource Identifier (URI). A client requests a resource from a server by sending a request to a URI. The server processes the request by translating the URI to internal address data to access or manipulate the data, and then assemble the response.

One important aspect of the architecture of the world wide web is the use of abstract interfaces for component communication. These abstract interfaces are presented as connectors. A client and server each use a connector component. A contract exists between both connectors that define the application protocol that the connectors use to exchange data by using the HTTP protocol.

The application protocol defines the documents, the format, and the behavior of the exchange. Any protocol can be chosen. By using the connector concept, both the client and the server are largely independent and exchangeable. Each connector translates the documents exchanged on the communication channel to internal representations both on the server-side and on the client-side, and vice versa.

The OData protocol defines a contract by specifying a uniform protocol that has the necessary qualities of a RESTful protocol. For instance, a connector attached to an SAP backend system translates between ABAP APIs and OData entities; SAP Gateway is such a connector.

On the other side, a client connector translates between OData entities and the APIs of the consumer platform. The connector is specified here. As a consequence, any client platform with libraries supporting the contracted OData format can communicate with any server supporting the same contract.

JSON with Chrome or Firefox

Because OData uses the HTTP protocol, any web browser can be used to start exploring OData. OData currently supports the Atom and the JSON formats. JSON has significantly less protocol overhead than the Atom Publishing protocol, which is used by default. JSON can easily be consumed with Java Script and by SAPUI5.

By default the JSON protocol does not display properly in any browser. If you want to explore the OData protocol using JSON there are two options that we recommend. The first is to use the Firefox or Chrome browser temporarily as your standard browser and install the JSONView plug-in.

JSON with Any Browser

The second option allows you to use JSON with any browser. The recommended approach is to call the URLs with the additional query parameter sap-ds-debug=true. This will render the results in HTML format that can be displayed by any browser without the need to install a plug-in. Furthermore, the relative links have been activated so that you can follow them with just a click.

ATOM Protocol with Query Option sap-ds-debug=true

By default, the ATOM protocol also does not display properly as text in any browser. Browsers instead interpret the HTTP response as an Atom or News Feed and try to render the results accordingly. If you want to explore the OData protocol by using the ATOM protocol, there are two options. The recommended approach is to call the URLs with the additional query parameter $sap-ds-debug=true. This will render the results in an HTML format that can be displayed by any browser. It also makes the relative links active so that you can follow them by just clicking on them. Additionally, the developer can access various information such as the stack of runtime objects being called on the server.

ATOM Protocol with Query Option $format=xml

An alternative option is to use the query option $format=xml. This will render the results as text that can also be displayed by any browser. However, it lacks all the advanced options of sap-ds-debug=true.

Structure of an OData Service