Category Overview

The Foundation Patterns category comprises the following patterns:

	Pattern: Frontend Integration
Problem	How can client-side end-user interfaces that are physically separated from server-side business logic and data storage be populated and updated with computing results, result sets from searches in data sources, and detailed information about data entities? How can application frontends invoke activities in a backend or upload data to it?
Solution	Let the backend of a distributed application expose its services to one or more application frontends via a message-based remote Frontend Integration API.

	Pattern: Backend Integration
Problem	How can distributed applications and their parts, which have been built independently and are deployed separately, exchange data and trigger mutual activity while preserving system-internal conceptual integrity without introducing undesired coupling?
Solution	Integrate the backend of a distributed application with one or more other backends (of the same or other distributed applications) by exposing its services via a message-based remote Backend Integration API.

	Pattern: Public API
Problem	How can an API be made available to an unlimited and/or unknown number of API clients outside the organization that are globally, nationally, and/or regionally distributed?
Solution	Expose the API on the public Internet along with a detailed API Description that describes both functional and nonfunctional properties of the API.

	Pattern: Community API
Problem	How can the visibility of and the access to an API be restricted to a closed user group that does not work for a single organizational unit but for multiple legal entities (such as companies, nonprofit/nongovernment organizations, and governments)?
Solution	Deploy the API and its implementation resources securely in an access-restricted location so that only the desired user group has access to it—for instance, in an extranet. Share the API Description only with the restricted target audience.

	Pattern: Solution-Internal API
Problem	How can access to and usage of an API be limited to an application, for instance, components in the same or another logical layer and/or physical tier?
Solution	Decompose the application logically into components. Let these components expose local or remote APIs. Offer these APIs only to system-internal communication partners such as other services in the application backend.

	Pattern: API Description
Problem	Which knowledge should be shared between an API provider and its clients? How should this knowledge be documented?
Solution	Create an API Description that defines request and response message structures, error reporting, and other relevant parts of the technical knowledge to be shared between provider and client. In addition to static and structural information, also cover dynamic or behavioral aspects, including invocation sequences, pre- and postconditions, and invariants. Complement the syntactical interface description with quality management policies as well as semantic specifications and organizational information.

Pattern: API Description

Problem

Which knowledge should be shared between an API provider and its clients? How should this knowledge be documented?

Solution

Create an API Description that defines request and response message structures, error reporting, and other relevant parts of the technical knowledge to be shared between provider and client. In addition to static and structural information, also cover dynamic or behavioral aspects, including invocation sequences, pre- and postconditions, and invariants. Complement the syntactical interface description with quality management policies as well as semantic specifications and organizational information.

Foundation Patterns

Category Overview

Foundation

Pattern Index

Foundation Patterns

Responsibility Patterns

Structure Patterns

Quality Patterns

Evolution Patterns

Cheat Sheet