Patterns

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

API Key – How can an API provider identify and authenticate clients and their requests?

Aggresive Obsolescence – How can API providers reduce the effort for maintaining an entire API or its parts (such as endpoints, operations, or message representations) with guaranteed service quality levels?

Atomic Parameter – How can simple, unstructured data (such as a number, a string, a Boolean value, or a block of binary data) be exchanged between API client and API provider?

Atomic Parameter List – How can multiple related Atomic Parameters be combined in a representation element so that each of them stays simple, but their relatedness becomes explicit in the API Description and the runtime message exchanges?

Backend Integration – 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?

Community API – 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)?

Computation Function – How can a client invoke side-effect-free remote processing on the provider side to have a result calculated from its input?

Conditional Request – How can unnecessary server-side processing and bandwidth usage be avoided when frequently invoking API operations that return rarely changing data?

Context Representation – How can API consumers and providers exchange context information without relying on any particular remoting protocols? How can identity information and quality properties in a request be made visible to related subsequent ones in conversations?

Data Element – How can domain/application-level information be exchanged between API clients and API providers without exposing provider-internal data definitions in the API? How can API client and API provider be decoupled from a data management point of view?

Data Transfer Resource – How can two or more communication participants exchange data without knowing each other, without being available at the same time, and even if the data has already been sent before its recipients became known?

Embedded Entity – How can one avoid sending multiple messages when their receivers require insights about multiple related information elements?

Error report – How can an API provider inform its clients about communication and processing faults? How can this information be made independent of the underlying communication technologies and platforms (for example, protocol-level headers representing status codes)?

Experimental Preview – How can providers make the introduction of a new API, or new API version, less risky for their clients and obtain early adopter feedback without having to freeze the API design prematurely?

Frontend Integration – 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?

Id Element – How can API elements be distinguished from each other at design time and at runtime? When applying domain-driven design, how can elements of the Published Language be identified?

Information Holder Resource – How can domain data be exposed in an API, but its implementation still be hidden? How can an API expose data entities so that API clients can access and/or modify these entities concurrently without compromising data integrity and quality?

Limited Lifetime Guarantee – How can a provider let clients know for how long they can rely on the published version of an API?

Link Element – How can API endpoints and operations be referenced in request and response message payloads so that they can be called remotely?

Linked Information Holder – How can messages be kept small even when an API deals with multiple information elements that reference each other?

Link Lookup Resource – How can message representations refer to other, possibly many and frequently changing, API endpoints and operations without binding the message recipient to the actual addresses of these endpoints?

Master Data Holder – How can I design an API that provides access to master data that lives for a long time, does not change frequently, and will be referenced from many clients?

Meta Data Element – How can messages be enriched with additional information so that receivers can interpret the message content correctly, without having to hardcode assumptions about the data semantics?

Operational Data Holder – How can an API support clients that want to create, read, update, and/or delete instances of domain entities that represent operational data: data that is rather short-lived, changes often during daily business operations, and has many outgoing relations?

Pagination – How can an API provider deliver large sequences of structured data without overwhelming clients?

Parameter Forest – How can multiple Parameter Trees be exposed as request or response payload of an API operation?

Parameter Tree – How can containment relationships be expressed when defining complex representation elements and exchanging such related elements at runtime?

Pricing Plan – How can the API provider meter API service consumption and charge for it?

Processing Resource – How can an API provider allow its clients to trigger an action in it?

Public API – 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?

Rate Limit – How can the API provider prevent API clients from excessive API usage?

Reference Data Holder – How should data that is referenced in many places, lives long, and is immutable for clients be treated in API endpoints?

Retrieval Operation – How can information available from a remote party (the API provider, that is) be retrieved to satisfy an information need of an end user or to allow further client-side processing?

Request Bundle – How can the number of requests and responses be reduced to increase communication efficiency?

Semantic Versioning – How can stakeholders compare API versions to detect immediately whether they are compatible?

Service Level Agreement – How can an API client learn about the specific quality-of-service characteristics of an API and its endpoint operations? How can these characteristics, and the consequences of not meeting them, be defined and communicated in a measurable way?

Solution-Internal API – 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?

State Creation Operation – How can an API provider allow its clients to report that something has happened that the provider needs to know about, for instance, to trigger instant or later processing?

Two in Production – How can a provider gradually update an API without breaking existing clients but also without having to maintain a large number of API versions in production?

Version Identifier – How can an API provider indicate its current capabilities as well as the existence of possibly incompatible changes to clients in order to prevent malfunctioning of clients due to undiscovered interpretation errors?

Wish List – How can an API client inform the API provider at runtime about the data it is interested in?

Wish Template – How can an API client inform the API provider about nested data that it is interested in? How can such preferences be expressed flexibly and dynamically?