If you have created an API, you must configure it before you can publish the API to the API Developer Portal. Refer to API Settings for an overview of the available options in the API details view.
API Tab "Settings"
In tab Settings of the API details page you can provide the backend API implementation. You can configure the following options here:
Defining the API Endpoint
| In section Implementation, you need to enter the URL that the API Management will use to proxy a request made for this API. If you import your API from the PAS Administration, the API endpoint/location is automatically set. |
Choosing the API Type
In API Management, you can create two different types of APIs: Public APIs and private APIs. Refer to API Types: Public vs. Private for a detailed overview on the differences between the two types. During API configuration, you should make a considered decision about the API type: It is not recommended to change the API type once the API has been published.
Depending on the chosen type, the content below the Public API toggle button changes (in addition, see Defining the Visibility and Attaching Plans):
| By default, newly created or imported APIs are created as private APIs. A private API cannot be consumed by everyone: They require an API Key in order to be called. To consume a private API, a client and a contract must be created. Compared to a public API, private APIs require more complex configuration. |
| Enable the toggle button to change the type to public. A public API can be consumed by everyone (assuming no additional security policy has been set). It is also very easy to consume a public API: You just need to know its public endpoint. Clients do not need to register for a public API: Neither a client nor a contract are necessary. Compared to a private API, a public API requires less configuration. |
| If you change the type of the API, you must confirm your choice in a separate pop-up. Read the information carefully before you change the type. It is not recommended to change the API type once the API has been published. |
Defining the Visibility
For detailed information about the visibility concept, refer to The Concepts of API Management.
| If you have enabled the option Public API, you can define the desired visibility for your API below. |
| If you have chosen to make your API private, you need to attach at least one plan to section Attached Plans first. See Attaching Plans. The visibility is then defined for each plan separately. |
The handling is the same for both API types: Click on the option you want to apply.
| Visibility | Description |
|---|---|
| Organization Members (default) |
|
| API Management Users |
|
| API Developer Portal Visitors |
|
In API Management, a user can see all APIs for which he has explicit permissions (roles Viewer and Editor). The permissions are assigned in the corresponding organizations, refer to Administrating Organization Members > Applicable Roles.
In addition, a user can be assigned the profile api_management_admin in the user management (refer to Administration Guide) which makes him a "superadmin" who can basically see and do everything in API Management (refer to Administration for details).
Attaching Plans
| If option Public API is disabled, you need to attach at least one plan to the API. All plans that are available in the corresponding organization are displayed below. | ||||||||
Click on the image to run through the animated version once. Click again to repeat. | To attach a plan, drag them from section Available Plans to section Attached Plans. Once a plan is attached, you can configure the following options:
|
Feature in API Developer Portal
| In section API Developer Portal you can determine if you want to display the API on the landing page of the API Developer Portal. Enable option Feature this API to show this API directly on the portals's first page. This setting is valid for all versions of the API. |
API Tab "Documentation"
If the API is to be offered to a larger group of users, good documentation is helpful for further usage. An API definition file allows consumers to better understand how to use your API. If you want to test your API directly from API Management, it is necessary to have an API definition.
Adding API Definition
| API Management supports various types of definition files:
Open the drop-down list in field API Definiton Type to select the type you want to use. API definition files must be valid JSON or YAML files following the OpenAPI specification or valid WDSL files according to the WSDL specification. |
| If you want to load the API definition from a URL source, enter the URL in field API Definition URL and click Import API Definition to start the upload. |
| To provide a JSON or YAML file, just drop it on the editor below. The editor allows you to adapt the displayed definition. Manual changes are automatically saved, but using Import API Definition again overrides the manual changes. |
| A separate editor is available for definition type WSDL. Enter your definition manually. |
If you have imported the API from the PAS Administration, the API definition is populated automatically. Alternatively, you can load a definition from a URL, or add a definition manually:
| Definition Options | Instructions |
|---|---|
Adding a Definition Manually | If no definition has been imported, you can add a definition manually:
|
Loading a Definition from a URL | If no definition has been imported or if you need to update an existing definition, you can import a definition from a URL:
|
Updating a Definition | If the definition of an imported API needs to be updated, you have to do this manually as there is no automatic re-import:
|
Adding or removing policies does not enrich the Open API documentation. You need to adjust your documentation manually. For more information on REST documentation and how to add documentation to xUML services, refer to Bridge Guide > Documenting a REST Service.
API Tab "Policies"
A policy is a rule or a set of rules API Management uses to manage access to your APIs. Policies are applied to all API requests and represent a unit of work applied at runtime to the request by API Management. Policies are applied through a policy chain: when a request to an API is made, API Management creates a chain of policies to be applied to that request. The policy chain is applied to the request in a fixed order: Client policies are applied first, then policies added to plans, and finally policies added to the API itself (refer to Policies > Policy Chain for details).
Refer to chapter Policies for an overview of the standard policies supplied with Scheer PAS API Management. Page Attaching Policies explains how to attach and configure a policy.
On this Page:
Related Pages:
Related Documentation:
Overview
Content Tools