This overview provides practitioner-community feedback on the design patterns captured in the outstanding book: “Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges”. Patterns with feedback in alphabetical order:
 | 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? |
 | 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 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)? |
 | 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? |
 | 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? |
 | 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? |
 | 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? |