On Fri, 17 Apr 2020 at 12:16, Sanjeewa Malalgoda <[email protected]> wrote:
> By the time we export API we really do not know all underlying APIs > available in the upper environment. It will detect only when the API > imports to the environment. > Since API product developers have access to the publisher and see > underlying APIs exporting product selectively will not be a big issue. > However if users started to expose only API products to outside and let > users to consume them as sellable units then things might be changed. In > that case APIs will be just a building block unit to make sellable > products. In such cases CI/CD pipelines etc do not need to care about > underlying APIs. API products will move across environments and when > something needs to move across environments. Even Though we don't have > users follow that pattern I think it will adapt very soon. > This particular scenario Sanjeewa is talking about impacts subscribers because they will not even be aware of the APIs, since only the API Products are exposed(APIs will be in CREATED life cycle state and therefore will not show up on the dev portal). However the way API Manager implements this concept means that you cannot fully forget about the existence of underlying APIs when you are an admin/creator/publisher user. So because of this CI/CD pipelines also need to consider this in the same way. Since API Manager supports a hybrid of exposing APIs as well as API Products, it can become fairly complicated trying to support importing/exporting dependent APIs under the hood. We could consider this in the future, but at the moment this is not a major benefit compared to the changes that we will need to make to existing stable code to support this. > Thanks, > sanjeewa. > > > On Fri, Apr 17, 2020 at 11:22 AM Wasura Wattearachchi <[email protected]> > wrote: > >> Hi, >> >> Thank you for your opinion @Uvindra Dias Jayasinha <[email protected]>. >> >> When discussing the functionality to Generate keys (tokens) for API >> Products, currently we have the “apictl gen-keys” command to generate >> keys for *APIs*. It requires --name (-n), --version (-v), --provider >> (-r) and --environment (-e) flags to be mandatory. Basically, here, the >> corresponding API will be searched by name, version (since one API can have >> many versions) and provider, in the corresponding environment, and an >> application named default-apictl-app will be created (if not already >> exists) and subscribed to the API, and a key was generated. >> >> The above current logic should change as follows in order to incorporate >> the functionality to generate keys for API Products as well. >> >> >> 1. >> >> Make the flag --version (-v) optional since API Products do not have >> versions. >> 2. >> >> When a user is trying to get a key for an API (since the version is >> optional now) search by --name (-n) and --provider (-r) in the >> corresponding --environment (-e), >> 1. >> >> If more than one APIs have been retrieved while searching, it >> means that the API we searched has more than one version. So, display a >> message (error) to the user stating “<number-of-retrieved-APIs> >> versions of >> the same API are available. Please specify the API version and try >> again” >> 2. >> >> If only one API has been retrieved while searching, then subscribe >> the application to it and generate a key. >> 3. >> >> When the user is trying to get a key for an API Product, since API >> Products do not have versions, we can directly search by the --name >> (-n) and --provider (-r) in the corresponding --environment (-e) and >> retrieve the API Product, then subscribe the application to it and >> generate >> a key. >> >> >> I appreciate any thoughts and feedback on this as well. >> >> Thank you! >> >> On Thu, Apr 16, 2020 at 11:20 AM Uvindra Dias Jayasinha <[email protected]> >> wrote: >> >>> Great analysis Wasura. >>> >>> The unique thing to keep in mind regarding API Products is that they >>> have two different personas when viewed from the perspective of the API >>> Publisher and the API Subscriber. To the API Publisher, an API Product is a >>> different entity from that of an API. The dependence of a given API Product >>> upon one or more underlying APIs is evident. However from the perspective >>> of the API Subscriber, an API Product is no different from an API. In fact >>> the API Subscriber cannot tell the difference between the two. >>> >>> Keeping this in mind, see my comments inline. >>> >>> On Thu, 16 Apr 2020 at 10:13, 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. >>>> >>> >>> +1 to Approach 1. Since it is clear that an API Product is dependent >>> upon an API(s), I think it's okay to mandate that the API(s) already have >>> been imported as a prerequisite. This simplifies the implementation of the >>> apictl and does not require changing the existing API import/export >>> functionality. >>> >>>> >>>> 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. >>>> >>> >>> +1 for a new set of commands. It is cleaner, less complicated and means >>> that existing API specific functionality will remain the same. We can save >>> API Product archives in a separate folder to differentiate them from APIs. >>> >>> However for the gen-keys, we can use the same command since it is >>> essentially a subscriber functionality(Refer to explanation of the >>> different personas of API Products). In fact gen-keys should work for API >>> Products as is, without any further changes. >>> >>> >>>> 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> >>>> >>>> >>>> >>> >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 777733962 >>> >> >> >> -- >> *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> >> >> >> > > -- > *Sanjeewa Malalgoda* > Software Architect | Associate Director, Engineering - WSO2 Inc. > (m) +94 712933253 | (e) [email protected] | (b) Blogger > <http://sanjeewamalalgoda.blogspot.com>, Medium > <https://medium.com/@sanjeewa190> > > GET INTEGRATION AGILE <https://wso2.com/signature> > Integration Agility for Digitally Driven Business > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
