Anypoint API Governance Overview

A governance profile applies selected governance rulesets to a filtered group of APIs. API Governance then validates the APIs against the rulesets to determine governance conformance.

Governance rulesets are collections of rules, or guidelines, that can be applied over the metadata extracted from APIs in Anypoint Platform. Examples of things you can use governance rulesets to help enforce are:

APIs are governed if they are identified by the selection criteria of at least one of the governance profiles. If an API is governed, all versions of that API are considered one governed API. Subscription limits are set based on your organization’s purchased capacity and the UI gives information about usage and alerts when you are nearing or exceeding your subscription capacity.

API conformance indicates whether a validated API specification passes all of the required rules in one or more governance rulesets. If an API specification is included in multiple governance profiles, it must pass all of the rulesets in all of those profiles to be conformant.

API conformance status indicates whether the APIs that are included in your governance profiles pass all applied governance rulesets:

Nonconformance severity is categorized by percentage of passed rulesets among all required rulesets:

Governance status in the API Governance console shows the number of governed APIs, total number of APIs of supported API types, and subscription limit information.

You can view profile statuses in the API Governance console. Governance profile statuses are based on the percentage of conformant APIs in the profile:

Project errors are shown in the Design Center API Designer text editor page. The Project Errors section of the page shows functional issues and nonconformance messages found in the API specification that is open in the text editor.

The entire API, including all its aspects. In Anypoint Platform, aspects of an API might also be called just API in context with the product that is managing them. For example, in Exchange, API might refer to the API specification, documentation, and catalog. In API Designer, API might refer to the API specification. In API Catalog, API might refer to the API instance, policies, and contracts.

Parts of an API. Examples of API aspects include specifications, instances, catalog information, and documentation.

Details the functional and expected behavior of an API, as well as the fundamental design philosophy and supported data types. It contains both documentation and API definitions to create a contract that people and software can read.

A realization of the API specification to make the API functional.

An instantiation of the API implementation. An API can have multiple instances across different environments and gateways, which can be used by clients to make API calls. Instances that are configured but not deployed are also captured as part of this aspect.

Helps consumers understand and use the API, with content such as examples, use cases, and tutorials.

Properties related to an API’s entry in an API catalog, such as name, version, owner (contact), tags and categories. In Anypoint Exchange, these properties are associated with APIs in asset portal information.