This project is read-only.

Big Picture with WebAPI and MVC

Topics: Web Api
Jan 3, 2012 at 3:35 PM

I have watched many of Glenn's videos on the new WebApi framework.

I am convinced that our organization needs to create a WebApi so we can access our data in a consistent way by various clients.  (right now just MVC website, but later Win8 Metro, win phone, iPhone/iPad etc.)

I am having trouble understanding how a WebApi would be used by an MVC web app that uses the standard controller methods.  A few of our MVC views use JavaScript to make an Ajax call back to the server, but 99% of them post to a controller method where we call its ViewModel to gather the data objects that get sent back to the view.

How would I use my new WebApi in this scenario?  I can't see having my ViewModel once again call my WebApi on the same server it is on to get data, when I have full access to the db at that time.

Would anyone care to offer a little architecture guidance on this? 

Jan 3, 2012 at 3:52 PM

Genereally REST APIs are created to be stable and long lived APIs that service multiple (internal and/or external) applications.  REST has methods that help the API to evolve in non-breaking ways and all using a simple HTTP interface.  But like many people have stated, the WCF Web API is not only for building REST services.

You can use it to build a website like you describe where the only consumer is the website itself, but if you don't have a need to expose your data directly then why do it that way?  A valid reason might be AJAX calls like you point out, and since your website and service are both on the same domain you can call your data directly from javascript (other websites/subdomains would need CORS or JSONP support).

If you DO have a need to support multiple clients (like you mention phones, Metro etc), creating a good REST API does makes sense.  In that scenario you will probably call the API from your MVC code using the HttpClient class.  If you want you can also do it via Javascript by using CORS or JSONP for cross-domain calls, but that requires a slightly different way of building your website.. usually you need to access the data in code too (gathering/combining data like you mention).

Hope this helps! :)

Jan 3, 2012 at 4:16 PM

Sigg, thanks for your comments.

So if I were to create a rich webapi for various clients and wanted to use it on all of them, then in my controller, or for that matter my viewmodel, I would be using WebClient to make the calls into the webapi.

View Post back to Controller.

Controller creates a ViewModel.

ViewModel uses WebAPI via HttpClient to gather data. 

WebAPI uses EF to get data and return it to caller.

This approach seems odd because my ViewModel could clearly use the same EF code to gather the data  and skip the entire WebAPI call.

As mentioned before, and you acknowledged, we might use ajax everyonce and a while, but for the most part we want to continue using the MVC framework to do most of the work. 

So am I to conclude that until we have a need for a different client like win8/metro or WinPhone7 Silverlight, that spending time creating a webapi would be an extra layer that is not needed and would be hard to justify?

Thanks again for your comments.

Jan 3, 2012 at 5:02 PM

If you are going to host this service and website together in the same application then yes that is weird.. In that case you can just access your DAL/EF directly, and having both controllers and the Web API classes use the same shared data layer.
Just be careful about compatibility, REST when done correctly can evolve the API without breaking existing clients, and generally you have to be very strict about tying down your exposed APIs.  It's a question about keeping boundaries strict and compatibility high, and for that reason I usually separate the API into a separate application so it can evolve on it's own, and the website using it on its own as well.  You should think of your website as one of multiple clients, not a "special" one.
If you go this way you won't have EF code in your website for the stuff in the Web API, just code that accesses it remotely.

As for your last question, yes creating a Web/REST API is a commitment that costs time and resources.. so if you don't have a direct need for it right now, you should consider if its worth it or not.  But ff you are certain you will have other clients soon, then you should go this way :)  Just don't end up spending time creating code that wont be used in time.. more often than not projects change, get refactored and so on...

Jan 3, 2012 at 5:17 PM

Sigg, thanks for those comments.  We have some big decisions ahead of us.