ASP.NET MVC 4 Web API: HTTP Isn’t Just For Browsers AnymorePosted in Internet Technologies, Microsoft | Leave a comment
The samples and walkthroughs of the Web API in the ASP.NET MVC 4 beta have been proliferating ever since it was released a few weeks back. Rather than rehash them here, I’d like to point you in their direction and then spend some of this space to talk about the implications of this latest development in Microsoft’s web stack.
Jon Galloway’s announcement of the beta is a good start: http://weblogs.asp.net/jgalloway/archive/2012/02/16/asp-net-4-beta-released.aspx.
Scott Hanselman’s “One ASP.NET” post is also excellent: http://www.hanselman.com/blog/OneASPNETMakingJSONWebAPIsWithASPNETMVC4BetaAndASPNETWebAPI.aspx.
Henrik Nielsen’s blog is a treasure trove for getting a handle on the potential of Web API: http://blogs.msdn.com/b/henrikn/.
Finally, the official ASP.NET site has a Web API focused area: http://www.asp.net/web-api.
What you quickly discover as you survey these resources is that the Web API represents full recognition on the part of the Microsoft team that the browser is becoming just one platform among many for connecting people to information. More profoundly still is the elevation of HTTP as an application protocol that is no longer conjoined to browsers. Any kind of client that can communicate using the CRUD verbs of HTTP is a candidate for making use of the Web API; it doesn’t matter whether that client is a browser, a native phone application, or some sort of medical device that needs to communicate data in real-time.
The Web API presents developers with the opportunity to use a strongly typed object model that represents the full protocol and can host HTTP services as well as consume them. For example, the new HttpResponseMessage generics knows how to serialize model objects into the body of an HTTP response and can further negotiate content representations based on accept headers specified by the client. The HttpClient type is not tied to any HTTP server, and is optimized for handling asynchronous requests. This means that developers get to focus on the kind of application service they want without having to constrain their conceptions to the capabilities of a web browser. This results in a wider set of clients that can be supported with a single code base, and more options for hosting applications outside of IIS.
It’s an exciting time in the web stack. The eco-system of modular components that started cropping up when Microsoft opened up their ASP.NET MVC framework is exploding. Now that we have the Web API, I’m looking forward to an even richer set of possibilities ahead.