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.
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.