The API Registry should include:
- Features - Describes what the API is designed to achieve in a form human beings can digest
- Structures - A schematic description of the APIs, including URIs, data structures, security, etc.
- Capabilities - What is the peak load the API can handle (both projected and actual) and the performance pinch points;
- Sensitivities - Does the API consume or expose any data that may be subject to Regulatory Risk or privacy constraint, such as Payment Card data, Personally Identifiable Information, and so on.
The API Registry provides this capability, holding data on behalf of the API-Gateway and API Portal to provide a catalog of information for human beings to digest. The API Registry will also help an organization manage the lifecycle of an API, cataloging the supported versions and their promotion or retirement from the organization’s API inventory.
Going back to the point about logical vs. physical architectures, the API registry is the component that is likely to be manifested within other components in a physical architecture (most likely the API Portal), or indeed in many organizations may be federated across both API management and other systems in an organization’s stack. However, an idealist view of the API Registry is that this is a discrete component, specifically implemented to harbor an organization’s API knowledge.