Introduction
[Level T2] In the last post, I introduced PocoHttp which I have been working on. As I promised there, we can use it to access classic OData services in addition to as much as OData support we have in ASP.NET Web API. OData functionality currently provided in PocoHttp is limited at the moment but I will be building upon.
[UPDATE: PocoHttp package v0.1 is not available in NuGet. Just type in the package manager console PM>Install-Package PocoHttp or search for PocoHttp]
[UPDATE: PocoHttp package v0.1 is not available in NuGet. Just type in the package manager console PM>Install-Package PocoHttp or search for PocoHttp]
Why OData?
During the last few years, Microsoft has invested a lot in OData. Some other technologies have also been built upon it such as RIA services which is heavily used in the Silverlight world. So Microsoft has been pushing OData and marketing it as an open protocol but reality is outside Microsoft, adoption has been nill. I believe this has to do with issues regarding query syntax and paylaod.
Firstly, as we talked about before, community believes that OData services are not RESTful as query syntax is unique to OData (Darrel explains here). It also exposes the bowels of the server to the client which does not respect REST's client-server model. Personally I believe there is a place for some of the simpler query constructs of OData such as top and skip that could be implemented by non-OData services as well.
And payload is limited to specific data structures in XML and JSON. As for XML payload, I think AtomPub as data wrapping format is heavy and inefficient - not to say that it has not been realised of recent. Sending metadata to the client that consumes the data every second is not a very good idea - metadata was used once to build the client but the client is eternally doomed to receive that information until the day sun stops shining (there might be a way to turn it off but that is not the default design). So it is like a web service that sends its WSDL all the time.
JSON payload is definitely lighter - it contains some metadata but nothing to be concerned about. The JSON format has changed between versions 1 and 2 of OData and server could be sending V1 or V2 (etc) depending on the content. There is DataServiceVersion custom header that can be used to get the version number from the response but I think as a canonical HTTP implementation, it should have been implemented as part of content-type:
Content-Type: application/json;DataServiceVersion=2.0Or
Content-Type: application/odata2.0+jsonAnyhow, that is not a big problem and I will be using JSON format in this sample. You can ask for JSON using an Accept header or appending $format=json.
OK, with all this so why OData then? For two reasons.
First of all, ASP.NET team are working to support alternative formats that do not have all the extra metadata: plain JSON or XML. So OData is going to live much longer in an improved implementation.
Second reason is there is already a considerable adoption inside the Microsoft community. Many teams while moving to new shiny Web APIs might still have an existing OData services that they need to use along with the new ones.
Why use PocoHttp to access OData?
While OData has the problems we talked about, it is not short of one thing: tools and SDKs. You can easily use DataService<T> to consume OData services and the API even allows for automatic generation of data models for Entity Framework. You are fully abstracted from OData itself while using its all benefits.
So why would you ever want to use anything other than the existing tools to comsume OData services? Well, a few reasons.
With adoption of Web API increasing (which can be seen from the enthusiasm in the community), you will most likely start using Web APIs alongside OData ones. You would be building custom handlers to take care of authentication, tracing, caching, auditing, exception handling, etc and start to rely on them. But you would not be able to use these them with existing client tools since you need a client that is built upon the new HTTP pipeline in System.Net.Http.dll. That is PocoHttp!
Also you might want to harness the extreme powers that the client has in terms of queries it can run (which we touched in the last post) and limit them to a few handful essential but safe constructs - protecting your database and services. Then again that is one of the goals of PocoHttp.
New sample on the block
So I have created this sample on the PocoHttp that connects to OData sample services exposing Northwinds database.
This basically sets up PocoClient to retrieve data in JSON format. Since the version of the JSON could be V1 or V2, the code needs to be able to support both.
Show us some code
OK! Let's look at request setup. There are two ways to request for JSON: by setting the Accept header or by appending $format=json:
// 1
pocoConfig.RequestSetup = (request) => request.Headers.Add("Accept", "application/json");
// 2
pocoConfig.RequestSetup = (request) => request.RequestUri = new
Uri(request.RequestUri.ToString() + "&$format=json",UriKind.Relative);
PocoConfiguration is a set of configuration parameters which is passed to the client constructor. One the parameters is RequestSetup which is an Action<HttpRequestMessage> that allows for the request to be modified before sending it to the server.
On the way back we use ResponseReader function to read the content into the objects. It receives the response, formatters and element types and must return objects it has read (will be IEnumerable<T>)
public Func<HttpResponseMessage, IEnumerable<MediaTypeFormatter>, Type, Task<object>>
ResponseReader { get; set; }
So this is a property sitting on the PocoConfiguration. PocoHttp provides a default implementation but since the data we get back is wrapped inside OData top level envelopes, we have to provide our own implementation. We need to define Payload<T> types that represent the structure of the data we are receiving. I have defined one for V1 and one for V2.
The gist of what we need to do is:
The gist of what we need to do is:
- Create a generic type of the entity using MakeGenericType
- Call non-generic ReadAsAsync passing the type
- Use reflection on the result to read off the properties to unwarp and get to the entities we need
For example, the code for V1 looks like this:
In the example, I have used only Take and Skip but you can use direct Where clauses as well.
private static object ReadFromV1(HttpResponseMessage response,
IEnumerable<MediaTypeFormatter> formatters, Type type)
{
var outermostType = typeof(PocoHttp.Samples.ClassicOData.V1.Payload<>)
.MakeGenericType(type);
var result = response.Content.ReadAsAsync(outermostType, formatters).Result;
return outermostType.GetProperty("d").GetValue(result, null);
}
In the example, I have used only Take and Skip but you can use direct Where clauses as well.
Conclusion
While ASP.NET Web API is the future of providing services and data, there is a considerable number of existing OData services that still need to be consumed.
While existing OData client tools expose full features of OData abstracting the client from HTTP detailed, we outlined two reasons why you would want to use PocoHttp instead to consume these services: re-using HTTP pipeline handlers and limiting the client in terms of queries it can run so that the.
