Sound advice - blog

Tales from the homeworld

My current feeds

Thu, 2008-Dec-25

What is REST? (for SOArchitects)

REST is a state of the art technology for service-orientation and related disciplines. It and its related architectures define a set of constraints that support the principles of

Runtime discoverability a core property of a REST architecture, and is achieved through its Uniform Interface and use of hyperlinks (URLs in documents). Governance is applied separately at two distinct levels in the architecture:

  1. At an architecture-wide level. Document types, communication patterns, and resultant standard methods are standardised. This is known as the Uniform Interface. A standard document type on the Web is HTML. A standard communication pattern would be to issue requests to get a document until one is successful. A standard resultant method would be the "get" method.
  2. At a service or service inventory level, standardising the service contract in terms of a set of fine-grained identifiers (typically URLs) with individual capabilities and meaning of their fine-grained capabilities. Fine-grained capabilities conform to the architecture-wide standards. An example fine-grained identifier would be for the current state of a specific purchase order or employee record. As URLs these might be "http://orders.example.com/purchase/123" and "http://employees.example.com/bob".

Coupling of services and their clients is primarily to the architecture-wide standard document types and methods, and is minimised between services and their clients. Every client and resource are expected to implement every appropriate pattern of communication and every appropriate document type for transferring information. Thus, any client and service that it makes sense to plug together can be plugged together at runtime by specifying the appropriate fine-grained identifier and invoking methods on it. Any client that expects to download a purchase order and perform reporting on it can be pointed at runtime to a designated purchase order URL and work correctly.

REST communication patterns and their resultant standard methods are:

The communication patterns support:

Document types in REST typically include hyperlinks: Embedded URLs that allow the client to interact with another resource capability in either the same service or another service, discovering these new resources at run-time. Embedded scripts or other program data may be included for execution within an appropriately-secured sandbox.

By applying principles from the Web, REST architectures can evolve gradually over time. The following mechanisms support a rapid pace of architectural change, however never require the simultaneous upgrade of services or their clients:

The high level of interoperability and runtime-discoverability intrinsic to a REST architecture supports a number of additional features. Caching is built into communication patterns, allowing this feature to improve the efficiency of the architecture through caching proxies and other devices. Load balancing, high availability, and high scalability are inherently straightforward to achieve compared to a classical SOA.

An individual REST architecture has a defined set of methods and document types. However, architectures can overlap. A Web architecture can be extended with new document types and methods to form a more domain-specific architecture. Existing Web tools are able to operate in this domain-specific environment as far as commonality exists between the two. Due to the decoupling between methods and document types, many components that are agnostic to document type operate correctly in the domain-specific environment without any modification.

Benjamin