This project is read-only.

WCF HTTP Vrs WCF Data Services

Topics: Web Api
Jan 29, 2011 at 6:54 PM

I am confused. I thought all I had to do to create a REST, or HTTP based service was to expose a model as a Service with WCF Data Services and it was done!!! Is this complementary technology? It does not appear to extend the WCF Data Services technology, does it? Or is a different way of doing it? Is it OData? or does it give you the control to create your own REST implementation. Are you a bunch of "ALT.NET" guys that don't like OData? If it is not OData then what is it? and what should it be? Seriously I think OData sounds great but if there is a competing standard that is gaining support and this is about supporting that then I would love to know.



Jan 29, 2011 at 9:25 PM
Edited Jan 29, 2011 at 9:59 PM

WCF Data Services is one approach for exposing data-oriented / CRUD services over HTTP verbs. WCF DS takes an Entity Data model and exposes the entities directly for CRUD operations through OData. WCF DS offers an end to end story for exposing that model over the web through OData. It also offers other extensibilty points for using other sources, but the  out of the box solution uses EF. In order to achieve this WCF DS imposes a specific set of constraints on how the resources look, the uri format etc. So if you have an EF model, and want to expose it over HTTP, WCF DS is by far your fastest and richest solution.

WCF Data Services actually sits on top of WCF HTTP which it uses to expose it's services. A DataService is actually a WCF HTTP service. DataServiceHost is a WCF host.

HTTP however does not have the same constraints as OData. There are many systems that communicate in other formats like plain-old-xml, json, atom, or proprietry formats. For example, when building a RESTful system a common format to return is X Forms. For these types of situations, WCF HTTP is ideal as it does not place any constraints above what is defined in the HTTP spec. WCF HTTP also allows the same resources to expose multiple formats at the same time thereby supporting the needs of various clients. OData is one such format that we are looking to support. The difference in the support at this level is we do not enforce or know about an entity data model. OData just becomes one of many formats with the burden being on the developer to provide the model that will be represented as OData.

Here's a post that describes a perspective on REST and OData from the one of the REST community folks, Darrel Miller:

In summary I would say that depending on your scenarios you may choose WCF DS over directly working with our stack. In either case WCF HTTP is in the picture.

Hope this helps