On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana <[email protected]> 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. Thanks, sanjeewa. > > On Fri, May 19, 2017 at 6:37 PM, Sanjeewa Malalgoda <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> 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 < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[email protected]> >>>>>>>>> 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 <[email protected] >>>>>>>>>> > 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: [email protected] >>>>>>>>>>> Mobile: +94713117081 <+94%2071%20311%207081> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nuwan Dias >>>>>>>>>> >>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>> email : [email protected] >>>>>>>>>> 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 : [email protected] >>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Lalaji Sureshika >>>>>> WSO2, Inc.; http://wso2.com/ >>>>>> email: [email protected]; cell: +94 71 608 6811 >>>>>> blog: http://lalajisureshika.blogspot.com >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>> email : [email protected] >>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
