REST in brief

REST as an architectural pattern is formalized here. REST is not an architecture per se. It is rather a set of design principles that some concrete architectures may meet better than others. According to Wikipedia, the fundamental facts about REST can be summarized as:

• Application state and functionality are divided into resources
• Every resource is uniquely addressable using a universal syntax
• All resources share a uniform interface for the transfer of state to and from the client

If that sounds a bit too abstract or if you, like me, sometimes need something more concrete to make sense of it, let me expand and rephrase the fundamental REST facts as:

• Applications are built around resources
• Applications access resources using a protocol that is client/server, stateless and cacheable (for example, HTTP)
• Resources are described using common formats
• Resources are addressed using URIs
• Resources are manipulated using a limited and general purpose interface, for example the set of HTTP verbs: GET, POST, PUT, DELETE

So a typical true REST service will use HTTP verbs to work on its resources and expose those resources via URIs. Recognized examples of true REST implementations are Google’s GData service and the Ruby On Rails programming model.

Going deeper into the concepts and practices of REST is beyond the boundaries of this article. For more information on REST-ful services, I recommend you take a look at RESTful Web Services, by Leonard Richardson and Sam Ruby (O’Reilly, 2007).

Being an architectural pattern for designing services, REST is associated with AJAX simply because AJAX applications need a service-based back end. The question is, is there currently any REST in ASP.NET AJAX services? Frankly, not much. But it mostly depends on how tolerant you are regarding the absolute quantity of REST principles required to label a system as RESTful. If you just need a minimum quantity of REST principles to call a system RESTful, you can then include in the list any systems that don’t use SOAP and Web services. What many of these systems often do, though, is tunneling remote function calls over HTTP returning plain XML, or perhaps JSON, data streams. This is more or less what ASP.NET AJAX does. It uses HTTP to carry function calls using JSON data streams instead of SOAP. On the server, though, you find objects in what is really close to a RPC model. And RPC is the complete opposite of REST.

An RPC application is exposed as a web of related objects, each with its own contracted interface. The client must have intimate knowledge of the object identity in order to communicate with it. A RESTful Web application takes a different approach and aims at creating a relatively small set of common resources that clients can address using a uniform syntax. Furthermore, each resource addressed provides links to further resources so that at each stage the client knows where it could go without knowledge of the whole resource set.

In summary, the only REST that can be reasonably found in ASP.NET AJAX (despite the naming of some internal classes) is the use of HTTP (but limited to the POST verb) and JSON to execute calls.

Code-name Astoria

Astoria is the codename of a new Microsoft technology first unveiled at MIX07 and later incorporated in ASP.NET Futures. It is a library that facilitates the creation of services that are reachable over HTTP and expose their data through URIs. More importantly, any interaction with the service happens in terms of HTTP verbs invoked over resources and carrying JSON or XML data. Does it sound like Microsoft’s transposition of REST principles? Yes, it does.

The Astoria plaform is still young, fast evolving and far from the Beta stage. If you pay a visit to the Astoria site, though, you can learn more about its objectives and details. Astoria will probably not make its debut until the next major upgrade of ASP.NET, currently slated for late 2008 at the earliest. For architects and developers involved with the design of AJAX-oriented systems, script-callable WCF services are probably the best way to go today. Today you consume back end services using JavaScript proxies. This top-level aspect isn’t likely to change with Astoria, so switching to a new service model may be easier and, more importantly, affect only a portion of your system.