Newsletter Discussion

Abstract

REST is an architectural style for building large-scale networked applications. It is a description of the features of the WWW that made the Web so successful. REST describes a networked system in terms of data elements (resource, resource identifier, representation), connectors (client, server, cache, resolver, tunnel) and components (origin server, gateway, proxy, user agent).

A report on REST (Representational State Transfer)

Acknowledgement to Paul Prescod

What is REST ?

It is called Representational State Transfer (REST), and it applies the principles of the Web to transaction-oriented services, rather than publishing-oriented sites. When we apply the strategy in the real world, we do so using web technologies such as URIs, HTTP, and XML. Unlike the current generation of web services technologies, however, we make those three technologies central rather than peripheral -- we rethink our web service interface in terms of URIs, HTTP, and XML. It is this rethinking that takes our web services beyond the capabilities of the first generation technologies based on Remote Procedure Call APIs like SOAP-RPC.

REST is an architectural style for building large-scale networked applications. It is a description of the features of the WWW that made the Web so successful.

REST describes a networked system in terms of

• data elements (resource, resource identifier, representation)
• connectors (client, server, cache, resolver, tunnel)
• components (origin server, gateway, proxy, user agent)

1 Aspects of REST

Data elements are accessed through a standardized interface. Components communicate by transferring representations of resources through this interface rather than operating directly upon the resource itself. Connectors present an abstract interface for component communication, hiding the implementation details of communication mechanisms. Components use connectors to access, provide access or mediate access to resources. All requests made to connectors must contain all the information necessary for the understanding of that request without depending on any previous request, i.e. they are stateless. It is important that intermediaries are an explicit aspect of the architecture and because of REST's characteristics, these intermediaries can be more than just dumb routers, they can be active participants.

Since REST is an extracted description of the WWW, it is no surprise that the protocol that exhibits the most number of these aspects is HTTP. However, REST and HTTP are separate concepts - it is entirely possible to apply REST concepts to other protocols and systems.

Since most people see the immediate value of components and connectors, most discussion has been focused on the 'information architecture' aspects of REST - resources, representations, URI's, standardized interfaces, etc. This area is informally known as 'resource modeling'. Most examples are framed in HTTP messages and URI addressable resources. The theory is that many complex systems can be fully described and implemented with just pure HTTP.

Quick Review

REST is a model for distributed computing. It is the one used by the world's biggest distributed computing application, the Web. When applied to web services technologies, it usually depends on a trio of technologies designed to be extremely extensible: XML, URIs, and HTTP. XML's extensibility should be obvious to most, but the other two may not be.

URIs are also extensible: there are an infinite number of possible URIs. More importantly, they can apply to an infinite number of logical entities called "resources." URIs are just the names and addresses of resources. Some REST advocates call the process of bringing your applications into this model "resource modeling." This process is not yet as formal as object oriented modeling or entity-relation modeling, but it is related.

The strength and flexibility of REST comes from the pervasive use of URIs. This point cannot be over-emphasized. When the Web was invented it had three components: HTML, which was about the worst markup language of its day (other than being simple); HTTP, which was the most primitive protocol of its day (other than being simple), and URIs (then called URLs), which were the only generalized, universal naming and addressing mechanism in use on the Internet. Why did the Web succeed? Not because of HTML and not because of HTTP. Those standards were merely shells for URIs.

REST limitations

There is no free lunch. REST is not a panacea. The biggest problem most will have with REST is that it requires you to rethink your problem in terms of manipulations of addressable resources instead of method calls to a component. Of course you may actually implement it on the server side however you want. But the API you communicate to your clients should be in terms of HTTP manipulations on XML documents addressed by URIs, not in terms of method calls with parameters.

Your customers may well prefer a component-based interface to a REST interface. Programmers are more used to APIs and APIs are better integrated into existing programming languages. For client-side programmers, REST is somewhat of a departure although for server-side programmers it is not much different than what they have been doing for the last several years, building web sites.

REST is about imposing a programming discipline of many URIs and few methods. RPC allows you to structure your application however it feels best to you. Let it all hang out! If a particular problem can be solved with RPC, and future extensibility and security are not going to be issues for you, you should certainly use the looser approach.

The Best Part

The best part about REST is that it frees you from waiting for standards like SOAP and WSDL to mature. You do not need them. You can do REST today, using W3C and IETF standards that range in age from 10 years (URIs) to 3 years (HTTP 1.1).

Whether you start working on partner-facing web services now or in two years, the difficult part will be aligning your business documents and business processes with your partners'. The technology you use to move bits from place to place is not important. The business-specific document and process modeling is.

REST does not offer a magic bullet for business process integration either. What REST brings to the table is merely freedom from the tyranny of proprietary addressing models buried in RPC parameters. Do not be afraid to use hyperlinks and URI addresses in your business documents and processes. Specifications like SOAP and WSDL may make that near impossible, but that is a problem with those specifications, not with your understanding of your problem. If you use hyperlinks in your business document and process modeling (as you should) then there is a protocol that does not get in your way: HTTP.

Reference

http://webservices.xml.com/