Hi Chamila On Wed, 16 Sep 2020 at 09:15, Chamila Adhikarinayake <[email protected]> wrote:
> Hi Uvindra, > I feel like we should introduce a versioning capability to API product and > deploy a new version of the product if the underline API is changed. If we > automatically change the API product resources, existing users might get > affected. I think this is what we do when we need to modify an existing API > in a production environment. We create a new API version and role out the > new changes. So, It is not a good practice to change the APIs once it is > published. (introduce a new version instead of changing the API). In that > case, existing API product should not be changed as well :) > By having a separate UI tab that will allow Publishers to view API Products that are eligible to be updated and allowing them to decide when the API Product will be republished, should address this concern. The changes to the API Product will not be pushed blindly. Sometimes users want to update published artifacts deliberately. As you mentioned, versioning for API Products is an important aspect that we want to address in the future as well. > > > On Tue, Sep 15, 2020 at 9:44 PM Saranki Magenthirarajah <[email protected]> > wrote: > >> Thank you for the details Uvindra. >> >> Regards, >> >> On Tue, Sep 15, 2020 at 12:40 PM Uvindra Dias Jayasinha <[email protected]> >> wrote: >> >>> Thanks for your feedback Saranki. >>> >>> On Mon, 14 Sep 2020 at 18:53, Saranki Magenthirarajah <[email protected]> >>> wrote: >>> >>>> Hi Uvindra, >>>> >>>> +1 for this idea on auto updating the API products with underlying API >>>> changes. >>>> >>>> This requirement has been raised by several of our customers in the >>>> past as they find it difficult to update the relevant API products via the >>>> API definition everytime the underlying API gets updated. >>>> Some additional improvements I would propose in terms of API Product in >>>> APIM-3.X.X are as follows. >>>> >>>> 1. The edit option in API Definition for API product gets displayed >>>> only after refreshing the page which is lacking in user experience. >>>> 2. When the role assigned to a scope is deleted or renamed it >>>> throws error in both the underlying API(s) as well as in the API >>>> product. >>>> Unless we remove it via the API/API Product definition or create the >>>> same >>>> role again the issue still persists. If we can address this as well in >>>> the >>>> product it will add more value to this feature. >>>> >>>> The ability to handle changes that take place to roles that are >>> assigned to scopes is a limitation that we currently have unfortunately. >>> Fixing this will require migration of existing data so it is a bit outside >>> the scope of what we are trying to address here. >>> >>>> >>>> 1. In the suggested API Publisher UI, will there be options to >>>> update all the dependent API products at once and to update >>>> individually as >>>> well? Because some customers might prefer to do the auto update >>>> without getting their concern each and every time(one-time concern: >>>> maybe >>>> a configuration via deployment.toml to be applied globally) as there >>>> could >>>> be large no of Products which might be time consuming to be selected >>>> individually for updates. >>>> >>>> Yes this is a good point, we can have a select all option to allow all >>> products to be updated in one go. >>> >>> Regards, >>>> >>>> On Mon, Sep 14, 2020 at 5:42 PM Uvindra Dias Jayasinha < >>>> [email protected]> wrote: >>>> >>>>> As part of an effort in improving the API Products feature we are >>>>> considering automatically updating an API Product when any of its >>>>> underlying APIs are updated. >>>>> >>>>> Currently for example, if there is a change in an API Resources scope, >>>>> those changes will not be reflected in an API Product that uses those >>>>> resources unless the API Product is explicitly saved. Due to the fact that >>>>> API Products are created and managed explicitly by API Publishers and APIs >>>>> are created solely by API Developers the following scenario needs to be >>>>> taken into consideration when propagating updates. >>>>> >>>>> By default an API Product will be in published state. If an API >>>>> Developer changes the scope of an API resource that is used by the API >>>>> Product leading to the API Product being updated then, >>>>> >>>>> *1. Who has updated the API Product?* - Technically the API Developer >>>>> has updated the API Product since the change to the underlying API >>>>> Resource >>>>> was initiated by them. But this seems to break the permission model >>>>> because >>>>> it allows an API Developer to modify an API Product indirectly. >>>>> >>>>> *2. To what gateway environment should the API Product be republished >>>>> to?* - Determining the gateway environment the API Product is >>>>> published to is the responsibility of the API Publisher. Currently though >>>>> the ability to choose this is hidden, it will be available when Life >>>>> Cycles >>>>> are supported for API Products. Any updates that occur to an API Product >>>>> due to an API resource change will not apply till the API Product is >>>>> republished. But without a API Publishers intervention we are unable to >>>>> determine which gateway environments to publish to. Publishing to all >>>>> environments available by default might go against what the API Publisher >>>>> expects. >>>>> >>>>> *Possible solution* >>>>> Managing API Product updates due to changes in an API resource is a >>>>> valid requirement. But in order to solve it without crossing the >>>>> boundaries >>>>> established for API Developers and API Publishers a new window in the API >>>>> Publisher UI could be introduced to show API Products that have dependent >>>>> API updates. This would allow API Publishers to identify API Products that >>>>> need to be republished and enable them to initiate the process. >>>>> >>>>> Please give your feedback on the above. >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Uvindra >>>>> >>>>> Mobile: 777733962 >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>> >>>> >>>> -- >>>> Saranki Magenthirarajah | Software Engineer | WSO2 Inc. >>>> (m) +94 770403900 | (e) [email protected] >>>> blog: https://medium.com/@m.saranki >>>> <http://wso2.com/signature> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 777733962 >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> >> >> -- >> Saranki Magenthirarajah | Software Engineer | WSO2 Inc. >> (m) +94 770403900 | (e) [email protected] >> blog: https://medium.com/@m.saranki >> <http://wso2.com/signature> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Regards, > Chamila Adhikarinayake > Associate Technical Lead > WSO2, Inc. > Mobile - +94712346437 > Email - [email protected] > Blog - http://helpfromadhi.blogspot.com/ > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
