- Created by Annegret Bernhardt on Nov 10, 2023
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
Version 1 Next »
API Management uses a hierarchical data model that consists of five primary elements:
The main elements of API Management are Clients, Plans and APIs. All of them can contain Policy definitions. To be used, they need to be grouped by an Organization and related by a Contract.
Figure: Overview on the API Management Data Model
Element | Description |
---|---|
Organization | Almost everything in the API Management data model exists in the context of an organization:
Expert Advice We recommend the following best practices regarding organizations:
|
Client | A client is only required if you want to use a private API (refer to API Types: Public vs. Private). The client is the consumer of the API:
|
Plan | A plan is only required if you want to use a private API (refer to API Types: Public vs. Private). A plan is a set of policies that defines the level of service API Management provides for an API:
|
API | APIs in API Management represent real backend APIs (Application Programming Interfaces). An API is also known as a service, meaning anything that can be invoked remotely by some sort of client. API Management provides a way to turn unmanaged (raw) back-end APIs into managed APIs by attaching policies to them. Every managed API can be published as Public API or Private API or both (refer to API Types: Public vs. Private):
In API Management, users can create new APIs manually or easily import them from the PAS Administration. |
Policy | Policies are at the lowest level of the data model, but they are the most important concept: A policy is a rule or a set of rules API Management uses to manage access to your APIs.
Expert Advice We recommend the following best practices regarding policies:
|
Contract | A contract is only required if you want to use a private API (refer to API Types: Public vs. Private). A contract relates a client to an API, using a plan. |
Versioning
API Management supports versioning for APIs, plans and clients. All three elements share one behavior: They have to be determined to be available for use in the gateway.
- APIs must be
- Plans have to be
- Clients must be
While it is still possible to modify a published API and a registered client, a locked plan cannot be revised.
If modifications to the API Management configuration are necessary, you can do this by:
- Creating a new element.
- Modifying an existing element (only APIs and clients).
- Create a new version of an existing element.
Versioning allows you to modify the configuration of an existing element, but retain the previous version.
To create a new version of an element, open its details page and click New Version in the basic settings. | |
In the version wizard, Name and Description cannot be changed. Use field Version to enter a new name oder version number. Click Next to access the summary. If you are satisfied with the changes, click Create to add the new version. It will be saved to the element. You can enter numbers and text in the Version field which allows the use of version numbers (e.g. 1.0, 2.1 ...) as well as version descriptions (e.g. Gold, Super etc.). | |
Use the Version drop-down in the basic settings of the element to switch between the different versions. |
Visibility
The visibility concept of API Management enables a fine-grained access to APIs and defines which user groups can find them. The visibility resides on top of the permission system as another security layer. Visibilities are applicable to public APIs and plans for private APIs. The chosen visibility affects both UIs: The content of API Management as well as the content of the API Developer Portal from where API consumers can find the APIs. Relevant for the visibility is the identity management (IDM) group a user belongs to: A user who is part of the API-Management-User group can browse and find the same APIs in API Management and in the Developer Portal once logged in.
You can choose between three different visibilities:
Icon in API Management | Visibility |
---|---|
Organization Members (default) | |
API Management Users | |
API Developer Portal |
Visibility Example
Three APIs have been created in organization ACME. Each API is assigned a different visibility.
|
Organization Members (default) | ||
---|---|---|
APIs are secured by default: If you create a new API, the default visibility setting is Organization Members. Only members of the organization the API has been created in are allowed to see it. Example: API Management Users who are explicit member of organization ACME can see API 1, API 2 and API 3. | ||
API Management Users | ||
Select the visibility API Management Users to allow all API Management users to see your API. Example: All API Management Users or API Management Administrators can see API 2 and API 3, they do not need to be member of organization ACME. | ||
API Developer Portal | ||
Choose the visibility API Developer Portal to allow API Developer Portal users and visitors to see your API. Example: API Management Developer Portal Users and anonymous portal visitors without a PAS login can see API 3 only. |
- No labels