Work With Odata in Web API: Understand Odata in Web API
Hi all, I hope everything is fine. Me too. I recently got 3 a day leave (weekend and one leave day) and thought we would learn something new that can expand us more in the world of web programming. I thought, what can I learn? What to learn? Then suddenly one word came to mind. The previous day as I was sitting at my next desk at the office and I heard someone talking regarding Odata. (Oh, it was in their project.) That got me thinking. Now understand that I really don't know much about Odata and in my free time I need to learn.
As a result of that I thought I would spend a few hours this weekend learning about Odata. I did and cannot resist the temptation to write a few lines about it.
What is Odata? What's wrong with SOA?
When I was reading a few posts and articles I was seeing, people asked such questions as, what is the difference between Odata and the Web API, what is the difference between SOAP and Odata and many more. Hm, those technical jargons are not so transparent to people.
That often happens when one suddenly arrives at an ocean of technology for the first time. So, let's start our discussion. What's wrong with SOA. We know SOA is Service Oriented Architecture; we expose data in the form of a service. We write functions to get that data.
Let's think that we have written one function to return the employee name when someone will supplies the employee code. Working cool, but in the next data some other guy is asking to get an employee's address and he wants to supply the employee's name.
That is a new requirement. Hmm, I need to write another function. History repeats itself, in another fine morning another guy demands that he wants to get an employee phone number only when he supplies the employee code. Oh, again add another function to the existing service. Now, we know people are greedy and demanding, the new requirements will never stop. Then what is the solution? Shall we add a new function each time a new requirement arrives?
Don't worry, Odata is the solution. Let's understand what Odata is theoretically .
The Open Data (OData) Protocol is a data access protocol for the web. OData provides a uniform way to structure data, query the data, and manipulate the data using CRUD operations (Create, Read, Update and Delete). OData supports both AtomPub (XML) and JSON formats. OData also defines a way to expose metadata about the data. Clients can use the metadata to discover the type information and relationships for the data set.
The Odata protocol was initially defined by Microsoft and released under the Microsoft Open Specification Promise. Version 4.0 is being standardized at OASIS and released March, 2014.
So, as per our discussion, we know that SOA is Service Oriented Architecture that exposes a few functions to outsource data from the endpoint, this technique is pretty cool when the requirement is fridge or when we know the exact query pattern.
But in this scenario, when we don't know the user's requirements, we can expose our service by maintaining the Odata protocol. Then the client can fire their own query to get data.
The service will be more flexible depending on the client's needs.
Gives the idea of Resource Oriented Architecture (ROA)
The Odata protocol gives the idea of a Resource Oriented Architecture (ROA) where we can expose a resource and enable the user to run various ad-hoc quiries against the resources. This is similar to the approach in the database system where you have tables that represent data and the ability to create various queries. The only difference is that, in ROA we form and pass queries using an URL.
Why Odata with Web API?
This is the little misconception, Odata is not tightly coupled with the Web API or MVC. As we know, it's nothing but a protocol, so any service based application may follow this protocol. We can create a pretty cool WCF data service by maintaining the Odata protocol.
So, it's not like that, Odata will only work with MVC or the Web API.
Difference between Odata and REST
This is another misconception in developer's minds. Let's understand the difference clearly. REST is an architectural style that defines certain principals to be followed for a service based application. For example the REST principal says that the service URL should be like a local directory URL. There will be no query string or data passing mechanism at all. (Oh, we wil pass data in the form of an URL part but not by query string) in the URL. The client and server will be totally de-coupled and much more.
So, if our service or application follows those principals then we will say that, ok the service is a RESTFul service. But it's not necessary to be RESTful of all services, the service may be or may not be.
Understood? Cool, now as per our discussion, Odata is a protocol that will sit on top of a service. If the service maintains those protocols then the user will get certain benefits, like the user (read client application) is able to read data as per its need, not depending on the service's return value.
How to implement Odata in our service based application
To know that, you need to wait until our next presentation. Or you are too curious to implement Odata practically, I suggest you visit here to learn more about Odata and implement it practically.
Oh, one good thing to say is that there is an Odata services available online for public use. You can try them, here are a few URLs.
Conclusion:
I hope you have gotten a basic understanding of the Odata protocol, now in a future article we will see how to implement an Odata service using Microsoft technology. Please keep in mind that, Odata is a protocol and it's technology independent.
As we earn our bread by talking and writing programs in Microsoft technology obviously we will see how to implement Odata in the context of Microsoft technology.