Using OData in apps is so easy thanks to the RESTful API that lets us use HTTP directly & JSON results. But OData works directly against a data model with a limited set of operations and capabilities. You can do some customization but at some point you get beyond the point of data services.
So then it’s back to WCF Services where you can have oh so much control over the service but boy can it get complex, especially when you want to leverage various protocols in WS-* e.g., security, etc. And you have to speak the language of the service which is different from one service to the next.
I see Web API as potentially the best of both worlds. I get to have control of the logic in my service, but I can consume it very easily with HTTP.
Value add to my education and this post via Glenn Block: “Definitely a big value prop for Web API is allowing multiple devices to consume the same applications while at the same time taking advantage of client capabilities.”
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
I agree with you. I’ve played around a little with Web API (when it was still called WCF Web API) and it was a helluvalot simpler than the regular WCF services. Can you get much simpler than Plain Ordinary HTTP?
What I’ve seen of ASP.NET Web API and how it’s been melded into MVC 4 makes it look even simpler (especially since the documentation and tutorials are so much better than before).
So I’m excited about it and looking for an excuse to use it in a production project.
Problem is that Web API doesn’t support $select when working against IQueryable (but supports the rest of Odata just fine) and thus it isn’t suitable for any large scale deployment because you’re forced to do SELECT * on everything.
Hence until and unless Web API supports $select it definately is not a replacement for WCF Data Services which is a shame because you know WCF Data Services is going to be EOLed in favor of Web API just like Linq to SQL with EF and it’s just not ready for any serious application.
It has been 2 years since these comments were posted. I am really trying to do things “right” with EF and /webAPI. I was told by a MS instructor that these where the tools to use going forward.
Both comments above would lead e to believe that WebAPI is not the tool to use with EF. However, since WebAPI no longer requires select * from – is WebAPI the way to go when accessing data from EF?
I have a project that will require data going to mobile devices as well as web sites. The data is being stored in azure. so that has created a few challenges in itself.
I have the entity framework model being created with the database located in Azure. Now I am trying to figure out how to integrate WebAPI and EF-5.
Julie – do you have any books or classes on plural site that have a webapi example?
The issues above are particular to returning OData from WebAPI. There is a whole course on Web API’s ability to serve up OData on Pluralsight by Brian Noyes.
[http://pluralsight.com/training/courses/TableOfContents?courseName=aspnetwebapi-odata]
But by now (2 years later) I default to using Web API (and mostly I’m using EF with it) for back ends to web apps and creating services that return json.
If you peruse some of my recent MSDN Data Points columns [http://juliel.me/datapointscolumn], you’ll see evidence of that. (Oh, one that I’m thinking of is not coming out until April 2014 issues)
hope it helps