Unknown macro: {next_previous_links}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

While an API is the published interface, a corresponding service running in the back-end handles its actual implementation. APIs have their own lifecycle, independent from the back-end service they rely on. This section covers the following:

The default API lifecycle

The default API lifecycle has the following stages:

  • CREATED: API metadata is saved, but it is not visible to subscribers yet, nor deployed to the API Gateway.
  • PUBLISHED: API is visible in API Store, and eventually published if the Propagate Changes to API Gateway option is selected at publishing time.
  • DEPRECATED: API is still deployed into API Gateway (available at runtime to existing users), but not visible to subscribers. An API is automatically deprecated when a new version is published.
  • RETIRED: API is unpublished from the API gateway and deleted from the store.
  • BLOCKED: Access is temporarily blocked. Runtime calls are blocked and the API is not shown in the API store anymore.

The diagram below shows the general API and backend service life cycle elements.

Figure: API and backend service life cycle elements

API Publisher has a separate tab called Lifecycle using which you can publish APIs to the API Store, depreciate, retire and perform other operations to an API. The Life Cycle tab is only visible to and manageable by a user who is assigned the publisher role. For instructions on creating a user with the publisher role, refer to section User Management .

Let's take a look at how to perform some common life cycle operations on an API.

Publishing an API

  1. Log in to the API Publisher (https://<HostName>:9443/store) as a user who has the publisher role assigned. 
  2. From the All APIs window that opens, click on the API you want to publish.

  3. The API's overview window opens. Click the Life Cycle tab, which displays the API's available states.

    The Life Cycle tab is only visible to users with publisher privileges.

     

  4. To publish the API, select the PUBLISHED state from the drop-down list. You get three check boxes to select as follows:

    Propagate Changes to API Gateway

    Used to define an API proxy in the API Gateway runtime component, allowing the API to be exposed to the consumers via the API Gateway. If this option is left unselected, the API metadata will not change and you will have to manually configure the API Gateway according to the information published in the API Store.

    Deprecate Old Versions

    If selected, any prior versions of the API will be set to the DEPRECATED state automatically.

    Require Re-Subscription

    Invalidates current user subscriptions, forcing users to subscribe again.

  5. Select the necessary options and click the Update button to publish the API to the API Store. Note the API life cycle history visible at the bottom of the page. 

Publishing to multiple external API stores

API publishers can share an API to application developers who are subscribed to multiple tenant-specific WSO2 API Stores, in order to expose the API to a wider community. Follow the steps below to configure:

  1. Uncomment the existing <ExternalAPIStores> element in <AM_Home>/repository/conf/api-manager.xml file of the API Publisher node, and configure an <ExternalAPIStores> element for each external WSO2 API Stores that you need to publish APIs to. For example,

    <ExternalAPIStores>       
       <ExternalAPIStore id=”Store1” type="wso2">
          <DisplayName>Store1</DisplayName>
          <Endpoint>http://localhost:9763/store</Endpoint>
          <Username>xxxx</Username>
          <Password>xxxx</Password>
      </ExternalAPIStore>
</ExternalAPIStores>

    In above configuration,

    Element/AttributeDescription
    idThe external store identifier, which is a unique value.
    typeType of the Store. APIM 1.5.0 release supports only WSO2-specific API Stores. Other types will be supported in future releases.
    <DisplayName>The name of the Store that is displayed in the publisher UI.

    <Endpoint>

    		URL of the API Store.
    <Username> & <Password>

    Credentials of a user who has permissions to create and publish APIs.

  2. To secure the user credentials given above, add a secure vault configuration as follows:

    1. For each external API Store, add a configuration similar to the one below in <AM_HOME>/repository/conf/security/cipher-tool.properties file. 

      ExternalAPIStores.ExternalAPIStore.Password_{store_id}=api-manager.xml//APIManager/ExternalAPIStores/ExternalAPIStore[@name='External_Store_id_defined_in_api-manager.xml']/Password,true

    2. Add the following to <AM_HOME>/repository/conf/security/cipher-text.properties file:

      ExternalAPIStores.ExternalAPIStore.Password_{store_id}=[user_password]

    3. Generate encrypted values for the passwords using the cipher tool

    4. Use the encrypted password in the configuration in step 1.

  3. Start the API Manager server and create an API.

  4. Click on the newly created API and note a new tab called External API Stores added to the API Publisher console. 
     
    Note the following:

    • You can select multiple external API Stores and click Save to publish your API to them. 
    • If the API creator updates the API after publication to external stores, either the creator or a publisher can simply push those changes to the published stores by selecting the stores and clicking Save again. 
    • If the API creator deletes the API, each external store that it is published to will receive a request to delete the API from the store.

     


  5.  

    Subscribing to APIs from external stores


     

    Once APIs are published to the configured set of external stores, those will be appearing in those stores. But will be available in an advertise mode only. This means that external store users will get to know about those APIs, but in order to subscribe they should visit the original publisher store.


     

    For example, above we showed how to publish API1-1.0.0 into the external store ‘Store1’. Now in the Store1 API-1.0.0 will be visible. But if someone clicks on that API, there will be a link to visit original publisher’s store.

     



 



Similarly, you can deprecate, retire and block APIs. Next, see how to manage subscriptions and access tokens in Managing API Usage.

  • No labels
Unknown macro: {next_previous_links2}