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.
   3. 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.

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

Reply via email to