Sound advice - blog

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

• Standardised Service Contract,
• Service Loose Coupling,
• Service Abstraction,
• Service Reusability,
• Service Autonomy,
• Service Statelessness,
• Service Discoverability, and
• Service Composability.

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 "https://orders.example.com/purchase/123" and "https://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:

• Client-Server, as are classical SOA services
• Stateless, with a state deferred by transferring it back to the client after each request.

The communication patterns support:

• Caching, with implicit or explicit labelling of responses as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
• Layering, with the full fine-grained identifier passed into any request. A proxy acts as a shared server for one or more clients, taking requests and forwarding them, with possible translation, to services.

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:

• URLs are decoupled from methods and document types, and evolve separately. Redirection is supported in communication patterns to allow logical identifiers to change over time as required.
• Document types are decoupled from URLs and from methods, and evolve separately.
  • Must-ignore semantics on documents support the addition of information in future versions of a document without the need for versioning or explicit switches. This allows a legacy service to accept "future" versions of the document based on the controlled evolution of a single document type.
  • Content negotiation is supported in communication patterns to support must-understand content in new document versions. These new versions are identified differently to the old version, and parallel generation and parsing implementations must be supported in order to ensure interoperability of legacy and new services within the architecture.
• Methods are decoupled from URLs and document types, and evolve separately. A means for rejecting methods that are not understood or ignoring extensions to understood methods is supported in communication patterns. These features allow fall-back to existing behaviour where new communication patterns are not supported by both parties to a conversation. However, this axis of communication is more difficult to change than the other two. Therefore, a small set of general patterns is preferred over a large set of more domain-specific or architecture-specific methods.

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