OData - Everything that you need to know (Part 1)

[anubhavpandey]

Introduction

This series of blogs is an attempt to provide a comprehensive guide to OData and how it is consumed in the SAP world. There has been a lot of content on the Internet explaining what is OData, how the services and published and how to consume which is scattered and assumes that the reader has clarity already on some very important fundamentals. However, there are so many aspects which deserves more than just a mention. In this blog, we will try and cover the topic 360 degrees.

We start with the very basics of HTTP and then gradually build on to OData and finally conclude with a detailed end-to-end exercise on how to create an OData service and how to consume it.

How Internet Works?

It might sound to be an unrelated topic when the focus is on OData. HTTP is the common thread between the two. HTTP is the underlying protocol on which OData is based and also one of the most common language which is spoken on the Internet.

You would typically need a Web Browser, address of the document you want to read or the URL (Uniform Resource Locator), a Web Server running at the system where the document is located.

Web Browser is a software which is responsible to retrieving and presenting resources on the web. Web Browser parses the HTML response received from the Web and prepares a DOM Tree. DOM stands for Document Object Model and it is a language-independent convention of representing objects in HTML. Web Browser acts as an interface between you and the World Wide Web.

You can request for a document located somewhere on this planet by providing its address via the browser which sends HTTP requests to the web server. The Web server then sends back HTTP response that is parsed by the Web Browser for you to view the document on your machine.

HTTP stands for Hyper Text Transfer Protocol and as the name suggest it defines the semantics of what the browser and the web server can communicate to each other. The how part of the communication or the byte by byte transfer of the data packets across the network is not HTTP but it is done via TCP/IP protocols.

An important component in the story so far is also the Web Server. In a nutshell, Web Server is a server program which sits on a physical server and waits for requests from a client. Whenever a request is received the Web Server prepares a response and sends it back to the client using HTTP protocol. It is important to note that HTTP is not the only but, by far most commonly used protocol and that the client here can be a browser or any other software that communicates in HTTP.

Let us now try and put up a formal definition to the HTTP.

"HTTP is based on a Client-Server architecture style and it uses a stateless request/response protocol to communicate between the client and the web server. The HTTP protocol helps define what requests can be sent across by the client and response sent by web server. The communication of data over the network is however done using on TCP/IP protocol".

It is evident that HTTP is based on client server architecture from our description till now, browser being the client which sends HTTP request and web server which sends the response back to the browser. But, why stateless?

Every single HTTP request that is received by the web server is forgotten after a response has been sent across. Web servers do not process an HTTP request by remembering the previous request. 

URI and URL are not the same thing

We mentioned a while back that you need to know the URL of the document you wish to view in your browser. Can I not mention a URI as an address to get the document on the web? Let us quickly understand the difference between the two.

URI or the Uniform Resource Identifier can be classified as a name, locator or both that identifies a resource uniquely.

URL (Uniform Resource Locator) is actually a subset of URI that not only identifies a resource uniquely but also provide means of locating the resource.

Defining the Request and Response

HTTP requests are sent with one of the defined Request Method that indicates the action to be taken on the resource. Following are the two most commonly used methods:

GET

This is used to retrieve information of the resource from the server.

POST

This method is usedto send data to the server.

For example, if you enter a text string on Google search page and press enter, it will generate an HTTP Request with GET method in the background. On the other hand, if you provide your username/password on a Login page and press enter a POST HTTP request will be send to the server.

HTTP Response from the Web Server comes with data and the status code. The status code provides a context to the response. For instance, if you do not correctly provide the resource location, the web browser will send you a response which you are not expecting. Along with the data response comes the status code, known universally in the HTTP world, that explains to the user what could be the reason for an unexpected response.

HTTP codes are 3 digit integers.

Code and Description

1xx: Informational It means the request has been received and the process is continuing.

2xx: Success It means the action was successfully received, understood, and accepted.

3xx: Redirection It means further action must be taken in order to complete the request.

4xx: Client Error It means the request contains incorrect syntax or cannot be fulfilled.

5xx: Server Error It means the server failed to fulfill an apparently valid request.

For example, status code 400 means Bad Request. It means that the server did not understand the request.

OData allow creation and consumption of RESTful APIs. In the next blog, I will cover what are RESTful APIs as the next stepping stone towards understanding OData.

Next Blog: OData - Everything that you need to know (Part 2)