On Mon, May 22, 2017 at 10:59 AM, Sanjeewa Malalgoda <sanje...@wso2.com> wrote:
> > > On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana <lak...@wso2.com> > wrote: > >> IMO normally in SDLC there is a state call MAINTENANCE and all >> functionality described in this thread falling into that. Seems like we >> have used wrong word call BLOCKED in previous versions. But from uses point >> of view they should able to put an API into maintenance mode without having >> much effort. >> > Yes i also agree with you. What most users do is temporary disable it due > maintenance and other incidents. We can change wording and keep > functionality there. > +1 to have the maintenance state in terms of the maintenance of API. But what about the blocking states such as block a subscription/ throttle level blocking? We can't put those under maintenance state. > > Thanks, > sanjeewa. > >> >> On Fri, May 19, 2017 at 6:37 PM, Sanjeewa Malalgoda <sanje...@wso2.com> >> wrote: >> >>> One other issue i see with ballerina editing or setting throttling tiers >>> is, business API owners need to handle that complexity. >>> Usually developers will develop API upto some point and let business >>> owners to handle it. Then they should be able to change API life cycle, >>> temporary blocking etc in simple manner. As a business API owner or system >>> administrator i don't want to go and edit ballerina. So i think its better >>> to keep block in life cycle states. >>> >>> Client applications will not implement to handle blocked situations. But >>> there are client applications which can handle throttle out scenarios and >>> some other error codes. We should not mislead those clients. >>> >>> Thanks, >>> sanjeewa. >>> >>> On Fri, May 19, 2017 at 10:51 AM, Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> These APIs are consumed by Apps. Apps don't understand what "Blocked" >>>> means. If an API is blocked, an App will throw an error irrespective of >>>> what the error response is. I'm pretty sure no one writes an App expecting >>>> an API to be blocked. >>>> >>>> In that case the only user set to whom this error response makes sense >>>> are to the API testers who are going to test this API using tools like CuRL >>>> during the period it is blocked. I think that is a very very small user >>>> percentage and the API will soon be unblocked anyway. Therefore I still >>>> think its a waste to burn "Blocked" as a standard state in the API >>>> Lifecycle, specially when we have many alternatives :). >>>> >>>> On Fri, May 19, 2017 at 10:42 AM, Ishara Cooray <isha...@wso2.com> >>>> wrote: >>>> >>>>> The provided workarounds for blocking an api is fine with respect to >>>>> developer p.o.v >>>>> But is it providing the proper end user experience? >>>>> >>>>> End user(who is invoking the api) will not see the correct error >>>>> message unless it has sent a customized error messages for this blocking >>>>> scenario. >>>>> Will not this introduce more work for developer? >>>>> >>>>> It will be only a single click for developer to make an api 'Blocked' >>>>> if it has the life cycle state and end user will also receive correct >>>>> message. >>>>> >>>>> So UX p.o.v i think having Blocked state is better. >>>>> >>>>> wdyt? >>>>> >>>>> Thanks & Regards, >>>>> Ishara Cooray >>>>> Senior Software Engineer >>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>> WSO2, Inc. | http://wso2.com/ >>>>> Lean . Enterprise . Middleware >>>>> >>>>> On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>> >>>>>> Blocking an API temporarily can be a valid scenario. And we already >>>>>> have 3 ways of doing it (1 for admin 2 for API developer). What I'm >>>>>> saying >>>>>> is that "Blocked" is never a standard state in any SDLC. So what's so >>>>>> special about an API LC? It is true that older versions of the product >>>>>> had >>>>>> this as a LC state, but I think it was wrong to have done that. >>>>>> >>>>>> @Lalaji, an API publisher has full control of his API. I don't think >>>>>> having a state called blocked and making it go through an approval adds a >>>>>> lot of value. Because there are many ways he can block his api, such as >>>>>> by >>>>>> changing the endpoint, changing the endpoint throttle limits, changing >>>>>> the >>>>>> code (ballerina). If I'm not approved to set a LC state as blocked, there >>>>>> are many other ways to block my API anyway. So I don't see it as a value >>>>>> addition. >>>>>> >>>>>> On Fri, May 19, 2017 at 9:37 AM, Lalaji Sureshika <lal...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> If we remove the 'blocked' state from API lifecycle and if we keep >>>>>>> the other options [set throttling limit/ballerina config change] to do >>>>>>> API >>>>>>> blocking,we will loose setting workflow extension to the particular >>>>>>> blocked >>>>>>> state.[Eg scenario-acknowledge users that API is temporally blocked via >>>>>>> a >>>>>>> custom workflow]..Isn't that with this,we are going to limit a >>>>>>> capability? >>>>>>> >>>>>>> Thanks; >>>>>>> >>>>>>> On Thu, May 18, 2017 at 3:44 PM, Lakshman Udayakantha < >>>>>>> lakshm...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Don't we have an extensible API lifecycle states in c5 >>>>>>>> implementation? If we have any user who doesn't want this blocked >>>>>>>> state can >>>>>>>> remove from state configuration and who wants this blocked state can >>>>>>>> keep >>>>>>>> this state in configuration. >>>>>>>> WDYT? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lakshman >>>>>>>> >>>>>>>> On Thu, May 18, 2017 at 3:22 PM, Nuwan Dias <nuw...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> If by any chance an API Developer wants to block his entire API >>>>>>>>> temporarily, he has two options. >>>>>>>>> >>>>>>>>> 1) Set the endpoint limit to 0req/min >>>>>>>>> 2) Use a temporary ballerina to send an error back to the >>>>>>>>> customer. >>>>>>>>> >>>>>>>>> On Thu, May 18, 2017 at 12:06 PM, Sanjeewa Malalgoda < >>>>>>>>> sanje...@wso2.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <nuw...@wso2.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I agree that "Blocked" is never a standard state in any SDLC. >>>>>>>>>>> Therefore I don't think its right to have a state called Blocked in >>>>>>>>>>> the API >>>>>>>>>>> Lifecycle as well. >>>>>>>>>>> >>>>>>>>>> There are existing users who heavily use this feature. If we are >>>>>>>>>> going to disable then we need to provide alternative. Lets think i'm >>>>>>>>>> API >>>>>>>>>> developer and i have my back end service as well. At some point i >>>>>>>>>> realized >>>>>>>>>> my back end not performing and i will temporary set blocked state >>>>>>>>>> until i >>>>>>>>>> fixed issue. User will see proper message saying access is blocked >>>>>>>>>> then he >>>>>>>>>> can skip invoking it. If we hack throttle etc to do same then end >>>>>>>>>> user will >>>>>>>>>> get incorrect information. Directly modify ballerina and send proper >>>>>>>>>> error >>>>>>>>>> message is good alternative. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Blocking is always a temporary action. If you need to take off >>>>>>>>>>> an API permanently the usual practice is to deprecate and retire it. >>>>>>>>>>> Therefore it doesn't sound right to have a state called "Blocked" >>>>>>>>>>> in the >>>>>>>>>>> API Lifecycle. >>>>>>>>>>> >>>>>>>>>>> Moreover, I've never seen an API Publisher blocking his entire >>>>>>>>>>> API. There are cases when he needs to blocks certain Apps but never >>>>>>>>>>> his >>>>>>>>>>> entire API. So I think its a very edge case requirement to have a >>>>>>>>>>> Blocked >>>>>>>>>>> state in the lifecycle and hence I don't think we should be >>>>>>>>>>> supporting it >>>>>>>>>>> as a first class feature. Therefore I suggest that we take off the >>>>>>>>>>> capability of blocking APIs from the Publisher app completely. The >>>>>>>>>>> admin >>>>>>>>>>> can still block APIs in the usual way (through the admin portal). >>>>>>>>>>> >>>>>>>>>> If user need to block API using throttling in admin dashboard he >>>>>>>>>> need to be super admin of the system. Normal API publishers cannot >>>>>>>>>> create >>>>>>>>>> blocking policies. So if this is about blocking policy it will not >>>>>>>>>> work >>>>>>>>>> IMO. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> sanjeewa. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If by any chance this edge case requirement comes up, the >>>>>>>>>>> publisher can either set the endpoint throttling limit to 0req/min >>>>>>>>>>> or put >>>>>>>>>>> up a temporary ballerina code to say the API is blocked. This way >>>>>>>>>>> we avoid >>>>>>>>>>> having many mechanisms of performing the same action (lesser >>>>>>>>>>> complications >>>>>>>>>>> = increased stability) and avoid having to support a feature for a >>>>>>>>>>> minority >>>>>>>>>>> user base (actually 0 in my personal experience). >>>>>>>>>>> >>>>>>>>>>> On Wed, May 17, 2017 at 11:50 AM, Yasima Dewmini < >>>>>>>>>>> yas...@wso2.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi All, >>>>>>>>>>>> >>>>>>>>>>>> As in the previous APIM versions, there were 4 ways to block an >>>>>>>>>>>> API/Subscription. >>>>>>>>>>>> >>>>>>>>>>>> *1. Block an API using API lifecycle "Blocked" state* >>>>>>>>>>>> >>>>>>>>>>>> API owner can block an API in publisher using API lifecycle. >>>>>>>>>>>> This will temporarily block an API and can be promoted to >>>>>>>>>>>> "Published" state >>>>>>>>>>>> again. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *2. Block a subscription* >>>>>>>>>>>> Publisher can block subscriptions using manage subscription. >>>>>>>>>>>> This can be used to block an app in Production level or in both >>>>>>>>>>>> Production >>>>>>>>>>>> and Sandbox levels. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *3. Throttle level blocking* >>>>>>>>>>>> An specific endpoint can be blocked by setting Production and >>>>>>>>>>>> Sandbox TPS to 0 in publisher . >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *4. Block an API using Admin dashboard*An API can be blocked >>>>>>>>>>>> using Black List feature in Admin dashboard. >>>>>>>>>>>> >>>>>>>>>>>> As per discussion within the team, we came to a conclusion to >>>>>>>>>>>> remove the "Blocked" state from API lifecycle which is used to >>>>>>>>>>>> block an >>>>>>>>>>>> API, since it is an edge case where API owner blocks his own API in >>>>>>>>>>>> publisher. If an API needs to be blocked it can be done using 2,3 >>>>>>>>>>>> or 4. >>>>>>>>>>>> >>>>>>>>>>>> Please share your thoughts on this. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Yasima. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> http://wso2.com/signatureYasima Dewmini >>>>>>>>>>>> Software Engineer, WSO2, Inc. >>>>>>>>>>>> Email: yas...@wso2.com >>>>>>>>>>>> Mobile: +94713117081 <+94%2071%20311%207081> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Nuwan Dias >>>>>>>>>>> >>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>> email : nuw...@wso2.com >>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>> WSO2 Inc. >>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>> >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nuwan Dias >>>>>>>>> >>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>> email : nuw...@wso2.com >>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> Architecture@wso2.org >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Lakshman Udayakantha >>>>>>>> WSO2 Inc. www.wso2.com >>>>>>>> lean.enterprise.middleware >>>>>>>> Mobile: *0717429601 <071%20742%209601>* >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lalaji Sureshika >>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>> email: lal...@wso2.com; cell: +94 71 608 6811 >>>>>>> blog: http://lalajisureshika.blogspot.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : nuw...@wso2.com >>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Software Architect - WSO2, Inc. http://wso2.com >>>> email : nuw...@wso2.com >>>> Phone : +94 777 775 729 <077%20777%205729> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Lakmal Warusawithana >> Director - Cloud Architecture; WSO2 Inc. >> Mobile : +94714289692 <071%20428%209692> >> Blogs : https://medium.com/@lakwarus/ >> http://lakmalsview.blogspot.com/ >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 <+94%2071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Gayan Gunarathne Technical Lead, WSO2 Inc. (http://wso2.com) Committer & PMC Member, Apache Stratos email : gay...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
