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 :)
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/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
