Hi all,
The functionality for Deleting APIs using the API Controller has been
implemented in [1].
By using a similar kind of approach, Deleting API Products has also been
implemented along with Listing API Products and Generating keys (tokens)
for API Products in [2] (Some modifications have been done to delete APIs
and API Products in [3]). Please find the below commands with the flags and
examples for the above-stated tasks.
Listing API Products
This functionality can be used to display a list of API Products in an
environment.
Command
apictl list api-products [flags]
Examples
apictl list api-products -e dev
apictl list api-products -e dev -q version:1.0.0
apictl list api-products -e prod -q provider:admin context:/myproduct
apictl list apis -e prod -l 25
apictl list api-products -e staging
Flags
Mandatory
-e, --environment string Environment to be searched
Optional
-l, --limit string Maximum number of API Products to return
-q, --query string Query pattern
--format string Pretty-print API Products using Go
Templates. Use "{{ jsonPretty . }}" to list all fields
Generating keys (tokens) for API Products
This functionality can be used to generate JWT token to invoke the API or
API Product by subscribing to a default application for testing purposes.
Command
apictl get-keys [flags]
The command is similar to the previous command that we had to generate
tokens for APIs, but the internal implementation has been modified in order
to generate tokens for API Products as well.
Examples
apictl get-keys -n TwitterAPI -v 1.0.0 -e dev
Flags
Mandatory
-e, --environment string Key generation environment
-n, --name string API or API Product to generate keys
Optional
-r, --provider string Provider of the API or API Product
-v, --version string Version of the API or API Product
Deleting API Products
This functionality can be used to delete an API Product from an environment.
Command
apictl delete-api-product [flags]
Examples
apictl delete-api-product -n TwitterAPI -e dev
apictl delete-api-product -n FacebookAPI -e production -r admin
Flags
Mandatory
-e, --environment string Environment from which the API should be deleted
-n, --name string Name of the API to be deleted
Optional
-r, --provider string Provider of the API
Note that the user may specify the provider flag or not since it is
optional. If the user has specified it, the search query will have it when
finding the API Product. (That means the search will be performed by the
name of the API Product and the provider) If the user has not specified it,
the provider will be omitted from the search query.
[1] fixes the issue [4].
The next step is to implement import and export functionalities for API
Products. [5] has been put to keep track of it and will discuss the folder
structure and more details of this in upcoming emails. I appreciate any
suggestions/inputs regarding this.
[1] https://github.com/wso2/product-apim-tooling/pull/285
[2] https://github.com/wso2/product-apim-tooling/pull/287
[3] https://github.com/wso2/product-apim-tooling/pull/292
[4] https://github.com/wso2/product-apim-tooling/issues/168
[5] https://github.com/wso2/product-apim-tooling/issues/291
Thank you!
On Thu, Apr 16, 2020 at 10:13 AM Wasura Wattearachchi <was...@wso2.com>
wrote:
> Hi all,
>
> This is regarding the issue
> <https://github.com/wso2/product-apim-tooling/issues/168> which requests
> to support listing and generating tokens for API Products through API
> Controller (apictl). Currently, we do not support any functionality related
> to API Products from API Controller side. Thus, we can introduce the
> following four (4) functionalities as a new feature (rather than a fix to
> the above-stated issue) in order to improve API Controller, additional to
> what has been requested in the above issue.
>
>
> 1.
>
> Import API Products
> 2.
>
> Export API Products
> 3.
>
> List API Products
> 4.
>
> Generate keys (tokens) for API Products
>
>
> Approaches
>
> Here, we can identify two (2) approaches for importing/exporting API
> Products.
>
> Approach 1 - Import/export without the dependant APIs
>
> 1.
>
> Import API Products
>
> Allow to import an API Product only if the dependent APIs have been
> already imported/created inside the API Manager. The main task here is to
> check whether the required resources to create the API Product are with the
> APIs in the API Manager.
>
> 1.
>
> Export API Products
>
> Allow to export/download an API Product without the related APIs inside
> the archive file.
>
> Approach 2 - Import/export with the dependant APIs
>
> 1.
>
> Import API Products
>
> Give freedom to the user to import an API Product along with the related
> APIs (archived together) only if the dependent APIs have not been already
> imported/created inside the API Manager. If the user tries to import an
> already imported API/APIs when importing the API Product, an error should
> be displayed.
>
> 1.
>
> Export API Products
>
> Allow to export/download an API Product with the dependent APIs inside
> the archive file.
>
> Comparison of Approach 1 and 2
>
> Approach 1
>
> Approach 2
>
> -
>
> Advantage
>
> Basically our rule would be "If you need to create a CI/CD process for an
> API Product, you should already have performed CI/CD process for all the
> dependent APIs".
>
> So as you can see, after doing CI/CD for each independent API you will
> have all the required APIs imported/exported. Then you can proceed with
> CI/CD for API Products smoothly since the required APIs have been already
> imported/exported. (If APIs are shared between two or more API Products,
> when importing those API Products, those shared APIs will not be
> imported/updated repeatedly, which is efficient)
>
>
> -
>
> Disadvantage
>
> Manually need to setup the CI/CD flows for API Products as the tool does
> not take care of updating the dependent APIs.
>
> -
>
> Advantage
>
> Easier to setup the CI/CD flows for API Products as the tool takes care of
> updating the dependent APIs.
>
>
> -
>
> Disadvantage
>
> If APIs are shared between two or more API Products, when importing those
> API Products, those shared APIs will be imported/updated repeatedly, which
> is inefficient.
>
> Commands to be used
>
> Here, we can identify two (2) ways such as using existing commands or
> using a new set of commands.
>
> Using existing commands
>
> 1.
>
> Import API Products
>
> Use the same command that we currently use to import an API “apictl
> import-api”.
>
> 1.
>
> Export API Products
>
> Use the same command that we currently use to export an API “apictl
> export-api”.
>
> Currently, name (-n) and (-v) are mandatory in the export-api command. But
> for products, we do not have a version. So we cannot make the version
> parameter mandatory. If we do not mandate it, no issue with products, but
> we need a way to download APIs without the version param. Then we can
> follow the approach like: if there is only one API with name:foo, we
> download it. But if there are multiple APIs with name:foo (with multiple
> versions) we give an error.
>
> 1.
>
> List API Products
>
> List API Products along with the APIs using the existing command “apictl
> list apis”. Further, we can improve this command by introducing a flag
> such as --api-products which can take either true or false. If true is
> given, the API Products will be listed along with the APIs and if false is
> given, only the APIs will get listed (which is similar to the current
> behaviour of “apictl list apis” command) not API Products. (This is
> recommended if you choose Command 1 in both import and export as stated
> earlier to maintain the consistency)
>
> 1.
>
> Generate keys (tokens) for API Products
>
> We can extend the current command “apictl get-keys” which has the ability
> to generate keys for APIs, in a way that it will have the ability to
> generate keys for API Products as well.
>
> Using a new set of commands
>
> 1.
>
> Import API Products
>
> Introduce a new command similar to what we currently use when importing an
> API. Example:- “apictl import-api-product”.
>
> 1.
>
> Export API Products
>
> Introduce a new command similar to what we currently use when exporting an
> API. Example:- “apictl export-api-product”.
>
> 1.
>
> List API Products
>
> Introduce a separate command as “apictl list api-products” to list API
> Products.
>
> Comparison of “Using existing commands” and “Using a new set of commands”
>
> Using existing commands
>
> Using a new set of commands
>
> -
>
> Advantage
>
> Can be used directly in CI/CD flow without worrying about the project type
> whether it is an API or an API Product. (Refer to the disadvantage of the
> other column for more information)
>
>
> -
>
> Disadvantage
>
> Since we are using “apictl export-api” (or “apictl import-api”) there is a
> wording issue.
>
> But IMO, this is not a problem, since API Product is in fact after all an
> API.
>
> -
>
> Advantage
>
> Since we have another command for importing/exporting apps as
> import-apps/export-apps, one could naturally go for a new command for
> import-api-product/export-api-product.
>
>
> -
>
> Disadvantage
>
> In CI/CD flow this can be a bit inconvenient because APIs and API Products
> are very similar, so would be its project structure. But from the
> automation script, it has to figure out which command to execute:
> export-api or export-api-product (same for import as well), since it does
> not know this project is an API or an API Product.
>
> Your feedback to choose the appropriate approaches and commands (with the
> problems that may arise) for each of the above tasks will be much
> appreciated. Furthermore, it would be great if new more simplified
> approaches can be identified in addition to the above-stated approaches.
>
> Thank you!
> --
> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
> <https://medium.com/@wasuradananjith>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
>
>
--
*Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
(m) +94775396038 | (e) was...@wso2.com | (b) Medium
<https://medium.com/@wasuradananjith>
[image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
