It would have been ideal if we had the commands in this format.
*apictl <verb> <noun>*
eg.
apictl list apis
apictl list api-products
apictl create api
apictl create api-product
apictl delete api
apictl delete api-product
But I don't think we are now in a position to change it.
Thanks,
Bhathiya
On Thu, Apr 30, 2020 at 11:05 AM Wasura Wattearachchi <was...@wso2.com>
wrote:
> 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>
>
>
>
--
*Bhathiya Jayasekara* | Senior Technical Lead | WSO2 Inc.
(m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
