(continued from previous page)

What's the difference between REST and SOAP, really? The two implementations of Web services architecture are actually completely different; they may accomplish much the same results, but they go about their jobs in entirely separate ways.

With SOAP, each Web service has its own URL, and a request made of that URL is submitted as a message in an XML enclosure. Each request uses an instruction that's part of the namespace of the service, which is itself explained through an XML scheme called Web Services Description Language (WSDL). So a Web client passes a message to the service, using the lexicon outlined by WSDL and enclosed in a SOAP envelope. The service then responds with results that are enclosed in a very symmetrical fashion, so that the queried element and the response tend to match up.

The key benefits of SOAP are that it is transport-agnostic (just because it uses HTTP now doesn't mean it has to in ten or fifteen years' time), and that it's easy to associate a Web service with an appropriate URL. That makes directories of Web services easier to assemble.

REST is actually a bit simpler to explain, especially to someone who hasn't grown too accustomed to SOAP. Unlike SOAP, REST relies entirely on HTTP. But because of that, its request language is already known; there are only four "verbs" in REST which translate directly to the GET, POST, PUT, and DELETE. So the need for WSDL on the request side is completely thwarted.

With REST, the item of data the client requests -- not the Web service itself -- is the target of the URL. For example, the field where a customer's surname would appear in a database may be the URL, whereas in SOAP, the URL refers to the service to which a request for that surname would be placed in an envelope. The server responds with a message in an XML envelope that pairs both the item that was requested and its response, which makes it easier for an auditing application to account for data transactions.

Is REST necessarily an easier way to go? It is if you're developing applications using a new concept called the model view controller scheme. These are the "composite" applications to which Microsoft's marketing literature refers; they involve three separate components which may be programmed in completely different languages, and may be running on separate processors. The model component sets up the data that's the subject of an application, whereas the view component prepares a meaningful relationship of that data for a human reader. This tends to translate well to systems where JavaScript or dynamic language code can do the modeling, and HTML can set up the view. The controller may be a server application that maintains the active state and integrity of the database.

It's an extremely sensible way to think of a network application, and it may be much easier to develop such a system because the three aspects of maintaining it can be delegated to separate development teams. But it almost mandates that the "what" of the application -- the part which the model component is setting up, and the view is preparing to lay out -- have a discrete name, without relying upon some Web service to give it a name later on during the transaction process. That's where the REST model may be a better fit.

Last November, Microsoft unveiled something called the ASP.NET Model View Controller Framework at a developer's conference in Las Vegas. There, one of the company's non-employee MVPs, author Dino Esposito, noted what he perceived to be the new framework's key benefit.

Summing up that benefit for his blog, Esposito wrote, "It uses a REST-like approach to ASP.NET Web development. It implements each request to the Web server as an HTTP call to something that can be logically described as a 'remote service endpoint.' The target URL contains all that is needed to identify the controller that will process the request up to generating the response -- whatever response format you need. I see more REST than MVC in this model. And, more importantly, REST is a more appropriate pattern to describe what pages created with the MVC framework actually do."

That's a sentiment Microsoft evidently took to heart. As Corporate Vice President Scott Guthrie wrote in describing his team's MVC implementation, "It includes a very powerful URL mapping component that enables you to build applications with clean URLs. URLs do not need to have extensions within them, and are designed to easily support SEO and REST-friendly naming patterns. For example, I could easily map the /products/edit/4 URL to the 'Edit' action of the ProductsController class in my project...or map the /Blogs/scottgu/10-10-2007/SomeTopic/ URL to a 'DisplayPost' action of a BlogEngineController class."

PDC in Los Angeles is a little over four weeks away, and BetaNews will be there to see how the first public betas of .NET 4.0 with REST perform in comparison to their predecessors.