Traditional REST

REST, as originally conceived, describes the architectural principles that power the overwhelming success of the World Wide Web. These principles include:

• URL addresses identify resources in the global Internet address space
• Resources embody information
• Resources are intangible, the information held in a resource is accessed by an immutable representation (copy) of the resource
• Typing is loose and is based on MIME types
• State is maintained by the client and is transferred to a function when a resource representation is computed
• Information is passed explicitly and often encoded in the URL of the resource
• The supporting protocol (HTTP) has a limited set of verbs expressing operations that may be performed on a resource

When applied together, these principles result in an information system that has important scalability and adaptability properties. For example:

• A URL address is both the location and the identify of a resource because all information required to compute the resource must come from the client and is encoded within the URL. Because all representations are copies of the resource, the resource may be provided by transparent intermediaries such as caches and proxies. The intrinsic caching of resource representations enables massive distribution of frequently accessed resources.
• The client must provide all state required to compute a resource, hence the computational engine is not responsible for saving state. This means that computation engines have no special knowledge and can be interchanged for each request. This substitutability means that a scaling of a function or service may be increased simply by increasing the number of computational engines. In Web architectures this is commonly called 'load-balancing'.
• Loose typing implies a tolerance for version mismatches between the client requesting a resource representation and the provider. A client will receive what the provide sends and is locally responsible for determining how to process the passed representation.
• A small set of verbs ensures that the underlying implementation of both client and server are not generationally dependent. Clients and servers can independently evolve and still interoperate.

Each one of these points is a desirable property - when combined in the Web they lead to the most successful, adaptive and scalable application yet devised.

URLs

URL addresses follow the familiar pattern of <protocol> ":" <//hostname> </delimited/path>. In a RESTful application the URL address becomes the vehicle for transferring state information from the client.

Some example can help make this clear. The Wikipedia is a quasi-public encyclopedia that uses REST addresses. For example, the definition in Wikipedia for REST is located at http://en.wikipedia.org/wiki/REST. If you click on this link, you will get a representation of the resource that contains the current description of REST. Notice that the URL encodes the notion that this is a Wiki (../wiki/..) and the topic (../REST). You could imagine a business system that supported the concept of a customer and purchase order using an encoding such as: ../Customer/id/4456 and ../Purchase-Order/id/221. All of these examples illustrate ways to encode information in the URL.

Using URLs to pass encoded information is challenging because of the inherent constraints of these addresses. The URL address space is linear while most application's have multi-dimensional data models. We shall see in a moment that NetKernel overcomes this problem by introducing a new multi-dimensional URI address space model to accommodate application data models.

Resources

When a resource is requested, an immutable copy of the resource, called a representation is returned instead. This implies that transparent, global caching can be used to improve the performance of the World Wide Web. The type of the returned representation is defined by the MIME type. The client is responsible for determining how, and even if, it is capable of processing the resource.

State

In RESTful applications, functions are stateless. All state information must be transferred with each request - this is the state transfer ("ST") part of "REST". The benefit of this characteristic is that performance scaling is achieved through load balancing. For example, Google exploits this characteristic in their stateless AJAX application designs. The Google Suggests application transfers the complete state of a user's query each time a key is pressed and returns to the client a list of search suggestions. Since the client always sends all requisite state, any equivalent function in a network can process requests from this application.

REST Summary

Because the architectural principles known as REST emerged from an examination of the Web, many have shortsightedly concluded that REST is bound to the specifics of the Web: the HTTP protocol and markup languages such as HTML and XML. This is not the case. REST is a general set of simple design principles that can be employed to build highly scalable systems.

Even more confusion arises from the debate over Web-services architecture. Two sides of the debate are anchored in the promotion of either SOAP or so-called 'RESTful Web services'. SOAP is an HTTP and XML based approach with both RPC and XML message model. RESTful Web-service are characterized by XML messages exchanged over HTTP with explicit URL service addressing.

As we shall show, the REST principles are not specific to a given application protocol, application domain, or resource type. Nor even are they a property of network architectures. The following sections will show how NetKernel defines a generalized REST abstraction that operates at a very low level and which provides a foundation for highly flexible and scalable software architectures. NetKernel enables all application development to utilize the proven scaling and adaptability properties of the Web and to exhibit extraordinary new properties previously unseen in computing models.