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?

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?

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?

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?

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?

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?

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?