RESTful Services With ASP.NET MVC

A RESTful service is a web of resources that programs can navigate. When designing a RESTful service, you have to think carefully about how your web will work. This means designing resource representations with links that facilitate navigation, describing service input somehow, and considering how consumers will navigate around your service at run time. Getting these things right is often overlooked, but they're central to realizing the full potential REST has to offer.

Today, humans navigate sites using Web browsers that know how to render HTML and other popular content types. HTML provides the syntax and semantics for establishing links between resources (<a> element) and for describing and submitting application input (<form> and <input> elements).

When a user clicks on an <a> element in the rendered page, the browser knows to issue an HTTP GET request for the target resource and render the response. When a browser encounters a <form> element, it knows how to render the form description into a user interface that the user can fill out and submit using either a GET or POST request. When the user presses a submit button, the browser encodes the data and sends it using the specified request. These two features are largely responsible for the success of the Web.

Using links in conjunction with the universal HTTP interface makes it possible to redirect requests to new locations over time and change certain aspects of security on the fly without changing the client code. A standard approach for forms means that you can add or remove input properties and change default values, again without changing the client code. Both features are very useful for building applications that evolve over time.

Your RESTful services should also somehow provide these two features through whatever resource representation you decide to use. For example, if you're designing a custom XML dialect for your service, you should probably come up with your own elements for establishing links and describing service input that will guide consumers through your web. Or you can simply use XHTML.

Most developers don't immediately consider XHTML as an option for "services," but that's actually one of the ways it was intended to be used. XHTML documents are by definition well-formed XML, which allows for automated processing using standard XML APIs. And since XHTML is also HTML, it comes with >, <form>, and <input> elements for modeling link navigation and service input as I described earlier. The only thing that's a little strange at first is how you model user-defined data structures-however, you can model classes and fields with <div> and <span> elements and collections of entities with <ol>and <li> elements. I'll walk through how to do this in more detail later in the article.

To summarize, there are several reasons to consider XHTML as the default representation for your RESTful services. First, you can leverage the syntax and semantics for important elements like <a>, <form>, and <input> instead of inventing your own. Second, you'll end up with services that feel a lot like sites because they'll be browsable by both users and applications. The XHTML is still interpreted by a human-it's just a programmer during development instead of a user at runtime. This simplifies things throughout the development process and makes it easier for consumers to learn how your service works. And finally, you can leverage standard Web development frameworks to build your RESTful services.

ASP.NET MVC is one such framework that provides an inherently RESTful model for building XHTML-based services. This article walks through some XHTML design concepts and then shows you how to build a complete XHTML-based RESTful service that you can download from the MSDN Magazine site.


[msdn.microsoft.com]