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
