!!! Overview[1]
[{$pagename}] is a key to effective [API Management] is having an inventory of an organization’s [APIs] that allows [API] consumers to digest the characteristics of the [APIs] available.

The [{$pagename}] 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 [{$pagename}] 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 [{$pagename}] 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.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [The Core Principles of API Management|http://nordicapis.com/core-principles-api-management/|target='_blank'] - based on information obtained 2016-12-19