8 API Implementation Lifecycle

After you have an API implementation in a Draft state that’s configured and tested, you’re ready to publish it. API implementations go through the same lifecycle phases as APIs, in addition to being published, new versions can be created, existing versions can be updated, and obsolete implementations can be moved to the trash.

Remember that after an API implementation is published, it can’t be changed. If you’re still configuring and testing the implementation, keep it in a Draft state until it’s ready for the next phase of the lifecycle.

If you want a general introduction to how artifacts interrelate in the overall lifecycle before exploring the lifecycle of API implementations, see Understanding Lifecycles.

Publishing an API Implementation

You can publish an implementation that contains real, non-mock data from the API Implementation page. Implementations can be published independently of APIs and can have separate versions as well. This lets you make changes to a published implementation, such as minor modifications or bug fixes, without requiring the API itself to be updated.

1. Click and select Mobile Apps > APIs from the side menu.
2. Select the API associated with the implementation that you want to publish.
3. Expand Implementations in the right section and click Manage.
   The API Implementation page is displayed:

   
   Description of the illustration api_impl_publish.png

   You can see the list of dependencies by expanding the Dependencies section of the API Implementation page. The API associated with the implementation and any other APIs or connectors that the implementation calls are listed. You can see which dependency is in a Draft state, a Published state, or is unresolved.

4. Select the implementation and click Publish.
   A dependency search is performed. If unresolved dependencies are found, the implementation can’t be published. Resolve the issue and try publishing the implementation again.

   
   Description of the illustration api_impl_publish_confirm.png

   If any API dependencies are declared through the Oracle-Mobile-API-Version header instead of through the package.json file, the API Designer isn’t aware of dependencies declared through the header and won’t prompt you with information when you publish the calling API. In this case, you must remember to publish the dependent API yourself.

5. If unpublished dependencies are found, click Publish All to publish all the listed unpublished artifacts.
   If you don’t want to publish all the dependencies with your implementation, click X to cancel the operation. You can either publish the dependencies individually or edit your implementation to remove them.

Creating a New Version or Updating the Version of an API Implementation

Implementations can be published independently of APIs and can have separate versions as well. This lets you make changes to a published implementation, such as minor modifications or bug fixes, without requiring the API itself to be updated. You can create a new version of an API Implementation that is in a Draft or Published state. If you want to make changes to a published implementation, you must create a new version of it.

If you have previously uploaded an implementation with a given version specified and that implementation is still in a Draft state, you can replace that version without incrementing the version number. This might be desirable if you’ve uploaded the implementation and find, after testing the implementation, that there are further changes that you need to make before you can publish the changes. After you’ve published a version, that version is final.

You can also update the version number of an implementation in a Draft state. The process for both is the same. You set the version attribute in the implementation’s package.json file.

1. Open the package.json file and change the version attribute. For example, change “version”:”1.0” to “version”:”1.1”.
2. Upload a zip file of the modified implementation to the associated API version.

Some key points to know about implementation versions are:

• Implementation versions are maintained independently of API versions. When you publish an API, the implementation isn’t published automatically.

• When you upload a new version of an implementation, it becomes the default version (active implementation) for that API. You can change the default version in the API’s Implementations page.

• The custom API’s Routing_BindApiToImpl policy defines the association between an API version and the implementation version.

Moving an API Implementation to the Trash

Remove an API implementation by moving it to the trash. If the implementation is needed later, you can restore it from the trash.

1. Click and select Mobile Apps > APIs from the side menu.
2. Select the API associated with the implementation.
3. Click Implementations in the API navigation bar.
4. Select the draft API implementation to remove.
5. Click Move to Trash.
   Only real implementations (not mock implementations) can be moved to the trash. If you’re moving the current default implementation to the trash, the next most recent version of the implementation is automatically set to the default. If no other implementations exist, the mock implementation is made the default.
6. Click Trash in the confirmation dialog if there are no dependency issues.

   If you think you or someone else might restore it later on, enter a brief comment about why you're putting this item in the trash.

To find out how dependencies can affect moving an artifact to the trash, see Moving an Artifact to the Trash. To restore an API implementation that’s in the trash, see Restoring an API Implementation.

Restoring an API Implementation

1. Click and select Mobile Apps > APIs from the side menu.
2. Select the API associated with the implementation.
3. Click Trash ().
4. Select Implementations in the trash drawer.
5. In the list of items in the trash, click by the implementation you want and select Restore from Trash.
6. Click Restore in the confirmation dialog if there are no conflicts.

If you’re restoring an implementation that was used by an API, the implementation won’t be restored as the default (active) implementation for the API. You’ll have to reset the implementation as the default from the Implementations page (select the API and click Implementations in the navbar).

Restoring an artifact can cause conflicts if a duplicate artifact already exists. To restore an artifact when a duplicate artifact exists, see Restoring an Artifact.