On Thu, Apr 30, 2020 at 4:46 PM Bhathiya Jayasekara <[email protected]> wrote:
> 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 > We don't have create operations right. It's the init. > apictl delete api > apictl delete api-product > However current delete commands aren't following the above convention. delete-api, delete-api-product looks not good. Shall we change? I believe they are introduced recently. > > 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 <[email protected]> > 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 <[email protected]> >> 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) [email protected] | (b) Medium >>> <https://medium.com/@wasuradananjith> >>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>> >>> >>> >> >> -- >> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc. >> (m) +94775396038 | (e) [email protected] | (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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Harsha Kumara* *PhD Student* *LaTrobe University*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
