OData protocol offers a rich and powerful query API over the data exposed from the data service.
Usually, the query description is aggregated to the URI of the service operation as the query string, then the service can translate that query back on to the queryable model and return the specific query desired by the client.
If you used it before, you must have seen the power it brings you in exposing the data to many clients and platforms to support each and every need.
In addition to WCF Data Services, ASP.NET WebAPI has too adopted this powerful approach. You can simply apply a [Queryable] attribute on your WebAPI service operation and expose the queryable model with support to this rich OData query API.
I understand the concept of OData which aims to serve and manage data over a standard and interoperable protocol, however I found several projects which revolves around building SOAP services with WS-* standards that wished to have that too.
For example, I could have a distributed .NET system with WS-* as well as binary encoding, but I simply want to support that powerful query API, not as a goal for interoperability, but as a goal of allowing the consumer to define the query that it wishes.
Yes, I could implement a generic a way for the client to provide the different parameters (‘top’, ‘skip’, ‘orderby’, etc) and apply it in the service, but that’s exactly what the libraries around OData provide, so naturally I wanted to build over that.
Basically, I needed a provider to build the standard URI from an expression on the client side and a way to translate it back on the queryable model on the other end.
Unfortunately, the implementation in the WCF Data Services remains private, and the ODataLib family seems to rely heavily on the http stack.
Googling a bit further, I found this nifty little project Linq2Rest which provided me with what I needed.
So.. how does it look like?
Similar to ASP.NET WebAPI, your service needs to expose the queryable model and decorate it with a simple attribute as follows –
That’s it, you’re done! Now you support OData standard URI requests on your queryable model.
As shown in the example, you can define the ‘MaxResults’ to ensure the maximum capacity of the result.
One last thing, you can use ‘IEnumerable<>’ as your return type if that is what you prefer in your case.
Another small feature – applying the query within the operation:
In some cases the need of applying the query request within the service operation might surface because you might want to do something with the end result before exiting.
If you encounter such a case, I prepared a method you can you use –
Normally, when you wish to call the service, you would create a channel and call the ‘GetFoos’ method.
I built some infrastructure on the client side to enable you to create query against this operation.
As you can see, you construct the channel as you normally would. Then, you can create a ‘QueryableGet’ from this channel and the operation you would like to use. Finally, it provides you with an IQueryable of that model which you can use to define your query and just enumerate over the results.
The support for asynchronous invocation relies on the fact that you have asynchronous operations defined on the service contract.
Once you do, you create the QueryableGet to map against the asynchronous operation, and that gives you a method that you can use to define your query and receive the task-based asynchronous operation that returns the results.
Both APM (Begin/End) and TPM (Task-based) are supported.
If you like to read a short description of the underlying implementation then keep reading, otherwise skip this part.
Basically, when you define the ‘QueryableGet’, it provides you with an IQueryable model that is built using Linq2Rest which its query provider builds a URI out of your expression.
Linq2Rest allows you to plug-in your own ‘RestClient’ and ‘SerializerFactory’ which it then activates to get the data and serialize the results. This enabled me to provide my own implementations where I simply inject the URI query into a message header, call the service operation which the developer defined as part of the ‘QueryableGet’ and return the results.
On the service end, the ‘QueryableAttribute’ injects an operation invoker which translates the query located in the message header back on to the queryable model returned from the service operation.
.. And that’s about it.
You can download the source code if you like and experiment with it yourself, it’s quite cool I must say.
In this sample I created queries against a service with NetTcpBinding.
Lastly, I’m afraid some of the operators are not yet supported.
For example, I couldn’t get ‘Expand’ to affect anything, even when working with Entity Framework. Plus, ‘Contains’ as part of a filter expression seems to be unsupported in the current version of Linq2Rest.