Home > REST Constraints > Layered System

Layered System

Short Definition

A solution can be comprised of multiple architectural layers.

Long Definition

A solution is defined in terms of architectural layers, where no one layer can see past the next. Layers can be comprised of consumers and services with published contracts or event-driven middleware components (intermediaries) that establish processing layers between consumers and services. In either case, logic within a given solution layer cannot have knowledge beyond the immediate layers above or below it (within the solution hierarchy).

  • Consumers are designed to invoke services without knowledge of what other services those services may also invoke.
  • Intermediaries are added to perform runtime message processing without knowledge of how those messages may be further processed beyond the next layer of processing.
  • The solution architecture is designed to allow new middleware layers to be added or old middleware layers to be removed without changing the technical contract between services and consumers.
  • Request and response messages must not reveal which layer the message comes from to their recipients.
  • At the consumer/service level, this constraint ensures an extent of information hiding, which naturally reduces consumer-to-service coupling.
  • At the middleware component level, this constraint advocates the use of cross-cutting agents capable of performing generic, utility-centric functions on messages exchanged by consumers and services.
  • These types of architectural layers can provide a flexible means of evolving a solution architecture and/or its underlying infrastructure while minimizing the impact on the solution logic itself.
  • The increased separation and distribution of moving parts performing solution logic processing can negatively impact the overall performance overhead (especially when middleware components are being reused by multiple solutions).
  • By limiting knowledge of the entire solution architecture to consumer designers, opportunities for optimizing the runtime performance of a solution can be lost.
Relationship to REST

The middleware components commonly introduced by the application of this constraint can directly support or enable Uniform Contract, Cache, and Stateless.

Related REST Goals

Modifiability, Scalability, Performance (Negative), Simplicity, Visibility