Overview
No subtopics in thissection
Developer Portal offers you an exclusive platform to safely expose your APIs to your target developers and partners.
Developer Portal also allows developers to self-register, learn about these APIs, and use the APIs in their applications.
To prepare to manage the APIs that you plan to make available in Developer Portal, consider the following questions:
How many Developer Portal instances you might need?
Which organizations might use Developer Portal?
Which users in the organization might use Developer Portal to consume the published APIs?
Which taxonomies and categories are required to organize the APIs?
For each Developer Portal instance, there is a Developer Portal object registered with the API Provider. A Developer Portal is associated with an organization. Multiple Developer Portal instances can share the same organization.
An API can be published to multiple Developer Portal instances. Developer Portal is capable of managing APIs published from API Gateway or any other provider application.
When an API is unpublished (removed) from Developer Portal, its metadata is deleted from Developer Portal, and the API is no longer available for access.
In addition to APIs published from a provider, you can also create APIs in Developer Portal by providing a corresponding specification. The APIs created in Developer Portal need not be associated with any providers.
You can download the published APIs from Developer Portal to have a copy of the API specification.
How do I create an API?
No subtopics in thissection
You can create an API using a file, URL, or by providing the source content.
Developer Portal supports the publishing of OData APIs from provider applications such as API Gateway. However, you cannot create OData APIs in Developer Portal by providing a specification.
This use case starts when you want to create an API and ends when you have successfully created an API.
Before you begin:
Ensure that you have the file, URL, or the required content for creating the API.
In this example, you create an API Petstore using the https://petstore.swagger.io/v2/swagger.json URL. The API is assigned to the provider, Provider1 and the community, Mobile_app_developer.
To create an API
Click the menu options icon from the title bar and click Manage assets.
Click APIs.
Click Create API.
Provide Petstore in the Name field.
Select Swagger from the Type list.
Select Provider1 in the Provider field.
Select Mobile_app_developer from the Community field.
Select URL from the Import with section and provide https://petstore.swagger.io/v2/swagger.json in the field.
Click Create.
The API is created. You can view the API from the API gallery page and the Manage APIs page.
Alternative steps
In Step 4, select any of the following API types from the Type list:
Open API. To create a REST API using an Open API specification.
RAML. To create a REST API using a RAML specification.
WSDL. To create a SOAP API using a WSDL specification.
In Step 7, select the required provider.
If you are creating the API for a third-party API gateway, ensure that the gateway is registered for the value to be available in the Provider field.
In Step 7, provide the following inputs to create an API from the Import with section:
File. To create API from a file. Click Browse and select the required file.
Content. To create API from the given content. Provide the required parser content using which the API has to be created. Ensure that the content does not have references to external files.
Next steps:
If the API lifecyle feature is enabled, then the newly created API is kept in the Draft state. For information about the API lifecycle, see Lifecycle Management of APIs and Packages.
Move the API to the Live state to make it available for consumers. For information on moving APIs to the Live state, see How do I change the state of an API to expose it to consumers?
How do I edit the basic attributes of an API?
No subtopics in thissection
Basic attributes of APIs include the API name, description, type, providers and communities associated with an API, and the API source.
This use case starts when you want to edit the basic attributes of an API and ends when you save your changes.
In this example, consider renaming the Pet_v1 API as Petstore_v1.
To edit the basic details of an API
Click the menu options icon from the title bar and click Manage assets.
Click APIs.
The list of APIs appears.
Click the edit icon next to the Pet_v1 API.
Click Save.
Your changes are saved. The API is removed from the public community. So, only the users who are a part of the Mobile_app_developer community can view or try the API.
How do I edit the advanced attributes of an API?
No subtopics in thissection
Advanced attributes of APIs include the API logo or icon, supporting documents, categories, and summary and description of the API resources.
Developer Portal supports providing of Markdown text and text in the supported languages for the following API attributes:
API summary and description
API categories such as tags, business terms, API grouping, and maturity status
API documents
Resource summary and description
Method summary and description
Sample Markdown text:
This use case starts when you want to edit the advanced attributes of an API and ends when you saved your changes.
In this example, consider adding API tags under API categories of the API, Petstore.
To edit the advanced details of an API
Click the menu options icon from the title bar and click Manage assets.
Click APIs.
The list of APIs appears.
Click the enrich icon next to the API that you want to edit.
Select API categories from the left pane and provide the new tag, Swagger and press Enter.
Click Save.
The tag is added to the API. Users can filter APIs based on tags in the API gallery page.
Alternative steps
You can provide or modify the following details of the API:
API info
API summary and description
Resource summary and description
Method summary and description
Sample Markdown text:
In this example, information is given under two different levels of headings.
Then, the output looks like this.
For information on Markdown text, see https://www.markdownguide.org/extended-syntax/.
How do I create a new version of an API?
No subtopics in thissection
When you create a new version of an API, the API gallery page displays the latest version of the API. You can view all versions of the from the Manage APIs page. The API details page has a drop-down list that displays all API versions.
You can create new versions of an API for the use of a different set of consumers or with different security policies. New data can also be updated to the existing meta-data when you create new versions of your APIs.
The new API has the same metadata but with an updated version. The version can either be a number or a string.
Different versions of an API can be added to different communities and can be associated with different packages.
This use case starts when you want to create a new version of an existing API and ends when you created a new version of an API.
In this example, consider creating a new version of the API, Petstore 2.0 and map the newer version to the Public community.
To create a new version of an API
Click from the title bar and click Manage assets.
Click APIs.
The list of APIs appear.
Click the version icon next to the API, Petstore.
Provide 2.0 in the Version field.
Select Swagger from the Type list.
Select Provider1 in the Provider field.
Select Public from the Community field.
Select URL from the Import with section and provide https://petstore.swagger.io/v2/swagger.json in the field.
Click Save.
A new version of the API, Petstore is created.
When you version an API, you can create versions from the newer version of the API and not from the older version.
In the example, note that the older API does not have the version icon appearing next to it.
Alternative steps
You can update the API by uploading a new file or by providing a new URL or pasting new content.
You can also map the API to another provider.
Next steps
All consumers can view the newer verison of the API as it is a part of the public community.
If the API lifecyle feature is enabled, then the newly created version is kept in the Draft state. For information about the API lifecycle, see Lifecycle Management of APIs and Packages.
Move the API to the Live state to make it available for consumers. For information on moving APIs to the Live state, see How do I change the state of an API to expose it to consumers?
Trying APIs
Trying a REST APITrying a SOAP APITrying a OData APIAuthorization fieldsDeveloper Portal allows you to try an API with required parameters.
You can try the required resource of an API by providing corresponding parameter values. You must also provide sufficient authorization details to have access to the API.
As an API consumer, it is important to test the endpoints of an API before putting them to use. Hence, Software AG recommends that you always test an API before consuming.
Trying a REST API
This section explains how you can test a REST API.
Pre-requisites
If the API that you are trying is protected with API key, JWT, or OAuth, then create an application to establish your identification. For information about creating applications, see Creating an application.
To try a REST API
Navigate to the Try API page using one of the following ways:
Click the Tryout icon in the corresponding API tile. Or,
Click Try API from the API details page of the corresponding API.
The Try API page appears. The resources that you can test appear in the left pane.
Select a resource and the required method.
Provide the following values in the Parameters tab:
Key. Key value of the parameter.
Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the following required values in the Headers tab:
Key. Value of the header key.
Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the authorization details from the Authorization tab.
For information about the authorization types and required inputs, see Authorization fields.
Select the required request form from the Request body tab and provide your request:
form-data. To send your request in the form of the key-value pairs. You can select Text and provide your form key and value or select File and attach the request file.
x-www-form-encoded. To send your request in the form of the encoded key-value pairs.
raw. To provide any request. You can provide the request in JSON or XML format.
None. To send the test request without a request body.
Click Send.
The response body and headers appear in their respective sections.
Trying a SOAP API
This section explains how you can test a SOAP API.
Pre-requisites
If the API that you are trying is protected with API key, JWT, or OAuth, then create an application to establish your identification. For information about creating applications, see Creating an application.
To try a SOAP API
Navigate to the Try API page using one of the following ways:
Click the Tryout icon in the corresponding API tile. Or,
Click Try API from the API details page of the corresponding API.
The Try API page appears. The SOAP methods that you can test appear in the left pane.
Select the required method.
Provide the following values in the Parameters tab:
Key. Key value of the parameter.
Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the required header details from the Headers tab:
To include header key value combinations, provide the following:
Key. Value of the header key.
Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
To include a SOAP header:
Name. A unique name to distinguish the provided SOAP headers, if there are multiple headers.
Click Add new namespace URI to provide unique Key elements and corresponding Value attributes for the header content. You can provide multiple key and value combinations by clicking Add new namespace URI.
Header content.
You can click Add SOAP header to provide more headers.
Provide the authorization details from the Authorization tab.
For information about the authorization types and required inputs, see Authorization fields.
If the SOAP API is protected with web service security (WSS) select the required authorization method from the Web Service Security tab:
WSS user token. Select this to provide WSS user name and password.
Provide the user name and password required for WSS authorization.
Select the Add nonce check box to include nonce, which is a randomly generated number that is included in the request header sent to the API server. Nonce is generated every time a request is sent to the API server and thus, adding a nonce to the request along with WSS user token prevents reuse of old communications.
Select the Add creation time check box to add a timestamp that the nonce was created. This value helps server to ensure that the outdated nonce values are not reused.
Select Password text to send password as plain text. Else, select Password digest to encrypt the password.
WSS SAML assertion. Select this to include SAML assertion for WSS authorization. You can either paste the assertion or upload the assertion file.
You can include both, WSS user token and SAML assertion, in your request. You can select either of these options, provide the required details, and then the other option without pressing Clear. So, the details provided for both options are included to the request.
In the Request body tab, provide your request in the form of key-value pairs or raw text.
Click Send.
The response body and headers appear in their respective sections.
Trying a OData API
This section explains how you can test a OData API.
Pre-requisites
If the API that you are trying is protected with API key, JWT, or OAuth, then create an application to establish your identification. For information about creating applications, see Creating an application.
To try a OData API
Navigate to the Try API page using one of the following ways:
Click the Tryout icon in the corresponding API tile. Or,
Click Try API from the API details page of the corresponding API.
The Try API page appears. The resources that you can test appear in the left pane.
Expand the required resource and click the required method.
In the Query builder tab, select the required query parameters and click Add.
The specified parameters are included as a query in the request URL.
Provide the following values in the Parameters tab:
Key. Key value of the parameter.
Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the following required values in the Headers tab:
Key. Type a header key value.
Value. Type the corresponding value of the key parameter.
You can click Add new and add multiple entries.
Provide the authorization details from the Authorization tab.
For information about the authorization types and required inputs, see Authorization fields.
Select the required request form from the Request body tab and provide your request:
form-data. To send your request in the form of the key-value pairs. You can select Text and provide your form key and value or select File and attach the request file.
x-www-form-encoded. To send your request in the form of the encoded key-value pairs.
raw. To provide any request. You can provide the request in JSON or XML format.
None. To send the test request without a request body.
Click Send.
The response body and headers appear in their respective sections.
Authorization fields
This section lists the steps to provide authorization details, for testing APIs, based on the authorization type applied to the corresponding APIs:
Authorization type | Procedure |
---|---|
For APIs protected with API key |
|
For APIs that require basic authentication |
|
For APIs protected with JWT |
|
For APIs protected with OAuth |
|
For APIs that do not require any authentication |
|
Applications
How do I configure onboarding strategy to process application or subscription requests?Creating an applicationHow do I create an application from Manage applications screen?How do I create an application from API details screen?How do I create an application from Try API screen?When you invoke a protected API from Developer Portal, you need to create an application requesting access to the API from the provider. Through the application, you can request access tokens from the provider by revealing a corresponding authentication such as username and password, OAuth, or JWT details.
During runtime, the provider recognizes the consumer’s identity through the application. The details passed from Developer Portal to the provider enables them to:
Control access to an API at run time (that is, allow only authorized applications to invoke an API).
Monitor an API for violations of a Service-Level Agreement (SLA) for a specified application.
Indicate the application to which a logged transaction event belongs.
You can create, view, and share applications from the Manage applications section.
Developer Portal sends the application requests from consumers to providers using the callback URL of providers. Configuring an incorrect callback URL can lead to communication issues between the provider and Developer Portal.
If an application onboarding strategy is configured, then the applications that you create will be processed based on the configured strategy. For information on configuring an application onboarding strategy, see How do I configure onboarding strategy to process application or subscription requests?
If you do not configure an onboarding strategy, then the registration requests are automatically approved.
You can view the status of requested applications from the Manage applications section. Once an application is approved, you can share the application with other users or user groups to alllow them use the application and invoke the corresponding APIs. When an application is shared, only the application owner can view the analytics and other cannot.
From the Trace application section of an application, you can view the stages that the application has passed through and their corresponding timestamp. These stages include application creation request,
You can trace the status and stages of an application using the Trace application section of an application. This section displays the various stages including application creation request, application request submit, application publish, application scope increase or decrease, and so on with the corresponding time stamp.
How do I configure onboarding strategy to process application or subscription requests?
This use case starts when you want to configure onboarding process to approve or reject the application or subscription registration requests.
Before you begin:
Ensure that you have:
Configure an approval workflow. For information on configuring an approval workflow, see How do I configure an approval workflow to process an internal approval onboarding strategy?
API Administrator privilege.
To configure onboarding strategy to process application or subscription requests
Click the menu options icon from the title bar and click Administration.
Select Onboarding.
From the Application/subscription onboarding section, enable any or all of the required strategies:
Internal approval. Select the required approval workflow from the Select a flow window that appears when you enable this strategy.
External approval. Select this if you want to process the requests using an external approval system. You can notify the required external approving system by creating a webhook. For information on configuring user sign up notifications to your external approving system, see How do I configure webhooks to notify user sign up and application requests to an external approval system?
Use the arrow keys next to these strategies to change their order. The strategies are followed by the order they appear.
Click Save.
The onboarding strategy to process application or subscription requests configuration is saved.
Next steps:
- Application and package subscription requests are processed based on the onboarding strategy.
Creating an application
You must create applications to invoke protected APIs.
You can create applications for an API from one of the following:
Manage applications screen
API details screen
Try API screen
You can create more than one application for an API.
How do I create an application from Manage applications screen?
This use case starts when you want to create an application and ends when you have created one.
In this example, consider creating an application app1 to access the API, Petstore that is published by the provider, Provider1.
Before you begin:
Ensure you have the API Administrator or the API Provider privilege.
To create an application from the Manage applications screen
Click the menu options icon from the title bar and click Manage applications.
The list of applications appear.
Click Create application.
Select Provider1 from the Stage list.
Select Petstore from the Select API field.
Provide app1 in the Name field.
Select the required callback URL of the provider.
Click Save.
The application is created.
Next steps:
Application is approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically.
Use application to invoke the API.
Perform the following to share an application:
Click the share icon next to the application you want to share.
From the Assign user/team screen, select the users or teams with whom you want to share the application. By default, this field displays only the users who belong to your communities.
Click Assign.
The application is shared with the selected users and teams.
Perform the following to revoke access to an application from specific users or teams:
Click the share icon next to the application you want to share.
From the Assign user/ team screen, click the delete icon next to the user or team from whom you want to revoke access.
Click Assign.
The access to the application is revoked from the selected users and teams.
When you create an application, the request is sent to the corresponding provider and approved based on the settings configured by provider. Applications in Developer Portal are approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically. After an application is approved, the application is ready to use. Check the Status field to ensure that an application is active.
To view the details of an application, click the application name.
You can trace the application’s stage from the Trace your application requests section of the page.
How do I create an application from API details screen?
This use case starts when you want to create an application and ends when you have created one.
To create an application from the API details screen:
From the API gallery page, click the view icon next to the API for which you want to create an application.
In the API details page, click the request application icon .
In the Request application screen, click Request.
If there is an existing application for the selected API, then the following screen appears:
You can select an existing one or create a new one. The application stage and API name appear in the corresponding fields on the Create application page. If you select to use an existing application, the scope of the application increases and you can invoke the API using an existing application.
Provide the application name and description.
Click Save.
The application is created.
Next steps:
Application is approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically.
Use application to invoke the API.
How do I create an application from Try API screen?
This use case starts when you want to create an application and ends when you have created one.
To create an application from the Try API screen
From the API gallery page, click the Try API icon next to the API for which you want to create an application.
In the Try API page, click Create new application.
The application stage and API name appear in the corresponding fields on the Create application page.
Provide the application name and description.
Click Save.
The application is created.
Next steps:
Application is approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically.
Use application to invoke the API.
Custom Asset Management
How do I configure the asset types to publish custom assets to Developer Portal?How do I add a custom asset to publish to Developer Portal?How do I add custom asset gallery to UI?In addition to APIs and packages, Developer Portal allows you to publish assets of your choice. This empowers providers to publish end-to-end development reference to their consumers.
As a provider, you can publish any kind of reference for your consumers using this feature.
You can add required asset types and define their properties. You can also create a gallery for the custom assets and display on the UI. Like APIs and packages, your end-users can view the custom assets and collaborate over them.
Custom asset publishing involves the following steps:
Add asset type. You have to first add the asset type, and configure its properties. You would have information that you require to describe the assets you publish to Developer Portal. You can specify the corresponding properties to provide information about each asset that you add to your custom gallery.
Add asset details. After defining the asset type, you can add assets along with their corresponding details.
Add asset gallery to Developer Portal. After you add the asset type, you can add the asset gallery to the UI for your consumers to view the custom assets.
The following use cases demonstrate the process of publishing custom assets using an example. These use cases consider Microservices as custom assets and list the steps of publishing them to Developer Portal.
How do I configure the asset types to publish custom assets to Developer Portal?
Before publishing custom assets to Developer Portal, you must configure the asset type. You can add an asset type and configure its properties from the Manage asset type page.
This use case starts when you want to add a custom asset type and ends when you add the required asset type and configure its properties.
In this example, consider adding the asset type, Microservice with the following properties:
Overview. A rich text field that states the overview of the asset (Microservice). This is an optional field.
Microservice document. An option to upload a file (Microservice document). This is an optional field.
Published On. A date time field to provide the date of the asset publish. This is an optional field.
Author. A text field that provides the asset’s author name. This is a mandatory field.
To add the asset type with the specified details
Click the menu option icon from the title bar and click Administration.
Click Manage asset types.
Click Add type.
Provide Microservice in the Name field.
Provide a description in the Description field.
Add the fields based on the information about custom assets that you want to publish.
When you add an asset of the defined type, you must specify values for the configured properties.
To add the Overview field:
a. Click Add properties.
b. Provide Overview in the Name field.
c. Provide Microservice Overview in the Display name field.
d. Select Rich text from the Select property type field.
e. Click Add.
To add the Microservice document field:
a. Click Add properties.
b. Provide Document in the Name field.
c. Provide Microservice Document in the Display name field.
d. Select File from the Select property type field.
e. Click Add.
To add the Published on field:
a. Click Add properties.
b. Provide Published On in the Name and Display name fields.
c. Select Date from the Select property type field.
d. Click Add.
To add the Author field:
a. Click Add properties.
b. Provide Author in the Name field.
c. Provide Author in the Display name field.
d. Select String from the Select property type field.
e. Turn the Required slider on.
f. Click Add.
Click Save.
The asset type is added.
Alternative steps
In Step 6, you can select one of the following from the Select property type to add the corresponding property for the asset type being created:
Property type Description Inputs to be provided Boolean Includes a boolean value field with options, Yes or No. Select the default value that must be displayed for the field.
Select whether this property is mandatory when adding an asset.Date time Includes a date time field. Select the default date and time that must be displayed in the field.
Select whether this property is mandatory when adding an asset.Enum Includes a drop-down list. Provide the values that must be displayed in the Possible values field.
You must provide a value and type a comma to provide the next value.
Select the default value that must be displayed in the field.
Select whether this property is mandatory when adding the asset.File Includes a file upload button that you can click to upload a file when you add the asset. Select whether this property is mandatory when adding the asset.
Note: You cannot provide a default value for this field.Image Includes an image upload button that you can click to upload an image when you add the asset. Select whether this property is mandatory when adding the asset.
Note: You cannot provide a default value for this field.Number Includes a number field. Provide the default value that must be displayed in the field.
Select whether this property is mandatory when adding an asset.Rich text Includes a rich text field. Provide the default value, with required formatting, to be displayed in the field.
Select whether this property is mandatory when adding the asset.String Includes a text box. Provide the default value that must be displayed in the field.
Select whether this property is mandatory when adding the asset.Tags Includes the tags field for the asset. Provide the default value that must be displayed in the field.
Select whether this property is mandatory when adding the asset.NoteWhen you create an asset type, the following properties are added by default:<br> *Icon*<br> *Name*<br> *Version*<br> *Summary*<br> *Tags*<br> Ensure that you do not add duplicate of these default properties.
After you add the required list of properties, you can:
Edit the details of the field by clicking .
Move the field up or down by clicking or . These fields appear in the order they are created. You can modify the properties as per requirement.
Remove a field by clicking .
Next steps
Add assets for the added type from the Manage asset page. For the procedure to add assets, see How do I add a custom asset to publish to Developer Portal?
Customize the custom asset gallery and asset details pages. For more information, see How do I add custom asset gallery to UI?
Configure accessibility of the custom asset gallery page. For information on configuring accessibility, see How do I assign access to a custom page?
How do I add a custom asset to publish to Developer Portal?
After you have added the required asset type, you can add the custom assets of the configured type.
This use case starts when you want to add a custom asset and ends when you add the required assets.
In this example, consider adding an asset for the type, Microservice, that is already configured.
To add a custom asset
Click the menu option icon from the title bar and click Administration.
Click Manage assets.
Click Microservice.
Click Add Microservice.
Provide information for the following default fields:
a. Click Browse and select the logo file.
b. Provide User registration in the Name field.
c. Provide 1.0 in the Version field.
d. Provide a summary for the asset.
e. Provide sign in in the Tags field and press Enter.
Provide information for the properties configured for the custom asset type:
a. Provide an overview for the microservice in the Overview field.
b. Click Browse from the Document field and select the required microservices document.
c. Select a date and time from the Published On field.
d. Provide an author name in the Author field.
Click Save.
Next steps
- Add the asset gallery and asset details pages to the UI. For more information, see How do I add custom asset gallery to UI?
How do I add custom asset gallery to UI?
You must add the custom asset gallery to UI for the assets to appear in UI. If you have not added this to UI, then it is not exposed to your consumers. For more details, see How do I add a new item to the top navigation bar?
The use case starts when you have added custom assets that has to be displayed in a gallery and ends when you have completed adding the page.
In this example, consider creating a gallery for the Microservice assets.
To add the custom asset gallery to the UI
Click the menu option icon from the title bar and click Administration.
Click the customize icon next to the active theme.
Select Pages and click Add.
From the Add page screen that appears, select Asset gallery page.
Click Next.
Select Microservice from the Select the asset field.
Click Create.
The asset gallery is added to the list of pages.
Click Add to add the asset detail page.
From the Add page screen that appears, select Asset details page.
Click Next.
Select Microservice from the Select the asset field.
Click Create.
The asset details is added to the list of pages.
Next steps
Add custom assets gallery to the top navigation bar. For information about adding a page to the top navigation bar, see How do I add a new item to the top navigation bar?
To add the custom asset gallery to the top navigation, provide the page target URL in the following format:
/pages/assets/custom_asset_type/gallery
For example,
The added custom assets appear in the gallery.
NoteEnsure that you make the changes to the active theme or you apply the theme in which you have made the changes. Also, note you cannot modify the default theme for including custom asset gallery. You must create a new theme and customize it accordingly.
Click the asset to view its details.
Customize the appearance of the asset gallery and asset details pages as per your requirements. For information about customizing pages, see How do I customize a block on a page?
Customize the accessibility of the asset gallery and asset details pages. For information about customizing access of custom pages, see How do I assign access to a custom page?
Lifecycle Management of APIs and Packages
Lifecycle Feature ConsiderationsHow do I enable the lifecycle feature for APIs and packages?How do I change the state of an API to expose it to consumers?How do I change the state of a Live API for maintenance?How do I change an API’s state to retire it from usage?How do I change the state of a package to expose it to consumers?How do I change the state of a Live package for maintenance?How do I change a package’s state to retire it from usage?By default, all APIs and API packages are accessible by consumers as and when they are published to Developer Portal. But, as an API provider, you have a lot of APIs or API packages that are under construction or maintenance. You can only expose the assets that are mature, tested, or well-documented for consumers. In such cases, the API lifecycle feature in Developer Portal allows you to expose the APIs that are ready for consumption. You can enable or disable this feature as per your requirement.
An API undergoes a lot of stages before it is ready to be exposed. The following section quickly takes you through these stages and the states that you can assign to those APIs:
In general, API developers develop the skeleton of an API, start implementing, mock it for testing responses, and then activate the API and publish it to Developer Portal. After this, API providers can use the Enrich API feature in Developer Portal to include the required logo or localized descriptions to API and its resources, and then test it again to ensure the performance of the API.
You can move API states in the following linear way based on the development of your APIs:
The default lifecycle states available in Developer Portal are:
- Draft. Default state of all APIs. The APIs published to the Developer Portal are kept in the Draft state initially. APIs in this state do not appear in API gallery. These are not available for consumers through applications and packages.
- Live. APIs that are moved to the Live state appear in API gallery. If you want to prevent consumers from using an API, you can move the particular API in the Live state to the Draft state. Hence, you can move APIs to the Draft state for the maintenance of those APIs.
- Retired. You can move the APIs that are no more used to the Retired state. APIs that are moved to this state cannot be moved back to the other states. Only administrators and providers can view the retired APIs and their details. However, you can create new versions from a retired API and expose them to consumers.
Lifecycle Feature Considerations
As an administrator or a provider, you must consider the following when you enable the lifecycle feature for APIs and packages in Developer Portal.
Visibility of assets
The following table lists the visibility and accessibility of assets on the UI based on user persona.
Use case | State of asset | API consumer | API provider | Administrator |
---|---|---|---|---|
View API in API gallery | Draft | |||
Live | ||||
Retired | ||||
View package in API packages (Package gallery) | Draft | |||
Live | ||||
Retired | ||||
Request application (for an API) or subscription (for a package) | Draft | |||
Live | ||||
Retired | ||||
Search an API or package using global search | Draft | |||
Live | ||||
Retired | ||||
Accessing an API or package using deep link URL | Draft | |||
Live | ||||
Retired |
State of restored APIs When you restore APIs from an archive, the restored APIs retain the same state from the backup archive. If APIs are backed up from an instance in which the API lifecycle feature is not enabled, then the restored APIs are kept in the Draft state.
State of migrated APIs When you migrate APIs to 10.15 from an earlier version of Developer Portal, the migrated APIs are kept in the Draft state. You can change their state as per your requirement.
Creating applications for APIs in Draft state Only administrators or providers can create applications for the APIs that are in the Draft state, in order to test them before exposing to consumers. Consumers cannot view or use those APIs.
How do I enable the lifecycle feature for APIs and packages?
By default, the lifecycle management feature is not enabled. You must enable the feature from the Administration section of Developer Portal to use the feature.
To enable the lifecycle feature
Click the menu options icon from the title bar and click Administration.
Click General.
Turn the Enable lifecycle slider on.
Click Save.
The lifecycle feature for APIs and packages is enabled.
The APIs and packages in the Draft state are not available for the use of consumers.
When you enable the lifecycle feature, all APIs and packages in your Developer Portal instance are moved to the Draft state.
Next steps:
Move the required APIs and packages to the Live state. For information about moving APIs and packages to the Live state, How do I change the state of an API to expose it to consumers? and How do I change the state of a package to expose it to consumers? respectively.
How do I change the state of an API to expose it to consumers?
This use case explains the steps to move an API to the Live state in order to expose it to consumers.
This use case starts when you want to move an API that is in Draft state to the Live state.
In this example, consider the API, API1 that is in the Draft state is moved to the Live state.
To move an API to the Live state
Click the menu options icon from the title bar and click Manage APIs.
Click the change state icon icon next to the API1.
Select Live.
Click Save.
The state of API is changed to Live.
APIs that are moved the Live state appear in the API gallery page.
Next steps:
Consumers can try the APIs that are in the Live state.
Providers can include the Live APIs to API packages and publish them for the use of consumers.
How do I change the state of a Live API for maintenance?
This use case explains the steps to move an API to the Draft state for performing any maintenance activity on that API.
This use case starts when you want to move an API to the Draft state from the Live state .
In this example, consider the same API, API1 that is in Live state moved to the Draft state.
To move an API to the Draft state
Click the menu options icon from the title bar and click Manage APIs.
Click the change state icon icon next to API1.
Select Draft.
Click Save.
The state of API is changed to Draft.
APIs that are moved to the Draft state do not appear in the API gallery page.
Next steps:
Providers or administrators can create applications to test the APIs that are in the Draft state.
Providers can perform the required maintenance activities to the Draft APIs and then change their state to Live for the use of consumers.
How do I change an API’s state to retire it from usage?
This use case starts when you want to retire an API that is in the Live or Draft state to prevent consumers from viewing it.
In this example, consider the API, API1 that is in Live state.
To move an APIs to the Retired state
Click the menu options icon from the title bar and click Manage APIs.
Click the change state icon icon next to the API1.
Select Retired.
Click Save.
The state of API is changed to Retired.
Next steps:
You cannot move the retired APIs to the other states.
You can create new versions of the retired API and expose to your consumers.
How do I change the state of a package to expose it to consumers?
This use case explains the steps to move a package to the Live state to expose it to consumers.
This use case starts when you want to move an package that is in Draft state to the Live state.
In this example, consider the package, Weather that in the Draft state moved to the Live state.
To move a package to the Live state
Click the menu options icon from the title bar and click Manage packages.
Click the change state icon icon next to the package.
Select Live.
Click Save.
The state of package is changed to Live.
Packages that are moved to the Live state appear in the API packages page.
Next step:
- Consumers can view the packages that are in the Live state.
How do I change the state of a Live package for maintenance?
This use case explains the steps to move a package to the Draft state for performing any maintenance activity on that API.
This use case starts when you want to move a package to the Draft state from the Live state.
In this example, consider the same package, Weather that is in Live state moved to the Draft state.
To move an package to the Draft state
Click the menu options icon from the title bar and click Manage packages.
Click the change state icon icon next to the package.
Select Draft.
Click Save.
The state of package is changed to Draft.
Packages that are moved to the Draft state do not appear in the API packages page.
Next steps:
- Providers can perform the required maintenance activities to the Draft packages and then change their state to Live for the use of consumers.
How do I change a package’s state to retire it from usage?
This use case starts when you want to retire a package that is in the Live or Draft state to prevent it from the view of consumers.
In this example, consider the package, Weather that is in Live state.
To move a package to the Retired state
Click the menu options icon from the title bar and click Manage packages.
Click the change state icon icon next to the package.
Select Retired.
Click Save.
The state of package is changed to Retired.
You cannot move the retired packages to the other states.