I completely agree with Nuwan. We should support updating published API without increasing the version. Think about a banking industry. If there is a critical bug in the mediation logic (lets say a masking logic), they should be able to fix the issue in the same version transparently without even letting customer know that there is a bug. Publishing a minor version with a minor backward compatible fix and asking customers to update their app to call latest minor version is not an option for these kind of industries.
Another example, what if we want to make some minor changes in API documentation? New API release for this kind of scenario is an over kill. Thanks. On Fri, Mar 31, 2017 at 12:04 AM Nuwan Dias <nuw...@wso2.com> wrote: > Hi Malintha, > > Yes, the workflow you have mentioned is the same one I'm proposing too. My > only concern is on a new state, because implementing that is a bit > complicated and this particular use case is not very common and therefore > there's little ROI :). > > Let's say we call this new state "MAINTENANCE", what's the difference > between bringing an API to "MAINTENANCE" vs "CREATED"? If we bring an API > to "MAINTENANCE", does it mean that there is a copy of the API left which > is in "PUBLISHED" state? > > @Fazlan, in theory it is true that updating a published API is wrong. But > in practice it sometimes happens because not everyone adheres to the best > practices 100% always. Users may opt to make backwards compatible changes > on the same minor version and some users don't even use minor versions at > all. So forcing to create a new version of the API and forcing their > clients to move to the newer version always is a bit too restrictive IMO. > > Thanks, > NuwanD. > > On Fri, Mar 31, 2017 at 8:41 AM, Rukshan Premathunga <ruks...@wso2.com> > wrote: > > Hi malintha, > > in c5 we decided to keep in the gateway even in the create state for > purpose of creator's testing. > so this will be fine. but keeping additional info in the create state not > something good. because create state is the state very first state when an > api is create. > > because of that I'm +1 for additional state. > > Thanks and Regards > > On Mar 31, 2017 8:10 AM, "Malintha Amarasinghe" <malint...@wso2.com> > wrote: > > Hi Nuwan, > > 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. > > If we are allowing this, I also feel a need of a new lifecycle state. > Because, in usual CREATED state, we do not allow the API to reside in > Gateway. But in *this* CREATED state, we are allowing the API to reside in > Gateway (which is the API with previous details). > > Let me summerise the complete flow, just to double check my understanding. > > 1. An API is in Published state. > 2. A Developer wants to make some technical changes to the API. > 3. Publisher makes the API Created state (or some new state). > > Now the API is not visible on Store, but existing subscriptions are still > valid. > > The previous API is available on GW, so existing invocations are working > without any issue. (This, we did not allow in CREATED state in C4) > > 4. Developer makes changes to the API > 5. Publisher accepts the changes (which means the API's lifecycle is > changed to Published) > 6. New changes are updated on the GW. > > > Thanks! > Malintha > > > 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 > > > > > -- > Malintha Amarasinghe > Software Engineer > *WSO2, Inc. - lean | enterprise | middleware* > http://wso2.com/ > > Mobile : +94 712383306 <+94%2071%20238%203306> > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- Rajkumar Rajaratnam Committer & PMC Member, Apache Stratos Senior Software Engineer, WSO2 LinkedIn: https://lk.linkedin.com/in/rajuu Mobile: +1 408 791 7640 Blogs: http://wso2tech.blogspot.com/ | https://medium.com/@wso2tech
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
