Hi Fazlan, On Thu, Mar 30, 2017 at 9:12 PM Fazlan Nazeem <fazl...@wso2.com> wrote:
> I don't think we should allow anyone to do changes to an already published > API regardless of whether he/she is a creator or publisher. > Any change done to an already published API is not the same API which was > published previously. Some of the changes could break the clients who are > already consuming this API. > > What if we enforce by design, that any update to an already published API > should be a new version of the same API. This way the updated API will go > through the same API lifecycle and we do not have the original problem > raised here. > In this approach what will happend to the existing subscriptions for the new API version? Let say we the change needs to go to all the subscribers and when we create a new API version we have to create all subscriptions that exists for the previous API. Correct me if I'm wrong. > > On Fri, Mar 31, 2017 at 12:12 AM, Nuwan Dias <nuw...@wso2.com> wrote: > > Hi Pubudu, > > The API will reside on the Gateway irrespective of its state. So this > action doesn't interrupt existing subscribers or existing consumers of the > API. It only prevents any new subscribers from seeing the API on the store > until republished. > > I have thought about introducing a new LC state as well. But that only > doesn't solve this issue. We need to build a mechanism to make a copy of > the API and store the developer's changes elsewhere until a publisher > approves the changes. Building that whole workflow is non trivial and > leaves a lot more to think about as well. Besides, the above usecase is not > standard practice since its not a good idea to make technical changes to > published APIs. But the reality is that the real world needs it and hence > we need to support it. > > Thanks, > NuwanD. > > On Thu, Mar 30, 2017 at 11:52 PM, Pubudu Gunatilaka <pubu...@wso2.com> > wrote: > > Hi Nuwan, > > AFAIU, in this case, we are not addressing the original issue. Original > issue here is changes made by API developers should not be reflected in > Store and Gateway unless the API publisher publishes the API again. Please > correct me if I am wrong. > > I don't think temporarily removing the API is the best solution if it is > already serving requests. > > What if we introduce another life cycle state and transfer the API to that > state until API publisher re-publishes the API. In this way, there is no > effect to the existing API. > > Thank you! > > On Thu, Mar 30, 2017 at 11:41 PM, Rukshan Premathunga <ruks...@wso2.com> > wrote: > > Hi Nuwan, > > If we demote API back to create, state how we are going to handle > subscription already have? Are we going to disable them till the API get > publish again? > > Also can we introduce or use the existing state to allow the API to be > update without un-publishing it. once it is done we can publish it again > with the changes. Because in if we demote to create state, we cannot have > subscription information right? > > Thanks and Regards > > On Thu, Mar 30, 2017 at 11:15 PM, Nuwan Dias <nuw...@wso2.com> wrote: > > Hi, > > On API Manager, API Developers (!= publishers) aren't able to publish an > API to the Store or Gateway. But on API Manager version 2.1.0 and before, > if an API Developer makes an update to an API that is already published, > the changes made by the developer are immediately reflected on the Store > and Gateway. This kind of beats the purpose of preventing API Developers > from publishing APIs to the Store and Gateway directly. > > For API Manager 3.0.0, I suggest that we prevent the API being updated by > API Developers after the API has gone beyond the "CREATED" state. API > Publishers should still be allowed to make updates to the fields they are > eligible for (non technical information). If someone badly needs to update > technical information of a published API, they should first bring the API > to the "CREATED" state, which will make the API disappear temporarily and > bring it back to "PUBLISHED" once the changes are saved. > > Thanks, > NuwanD. > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 <+94%2077%20777%205729> > > > > > -- > Rukshan Chathuranga. > Software Engineer. > WSO2, Inc. > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > > > > -- > *Pubudu Gunatilaka* > Committer and PMC Member - Apache Stratos > Software Engineer > WSO2, Inc.: http://wso2.com > mobile : +94774078049 <%2B94772207163> > > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 <+94%2077%20777%205729> > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > > > > -- > Thanks & Regards, > > Fazlan Nazeem > > *Software Engineer* > > *WSO2 Inc* > Mobile : +94772338839 > <%2B94%20%280%29%20773%20451194> > fazl...@wso2.com > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- *Prasanna Dangalla* Senior Software Engineer, WSO2, Inc.; http://wso2.com/ lean.enterprise.middleware *cell: +94 718 11 27 51* *twitter: @prasa77*
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
