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 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* >>> >>> >>> _______________________________________________ >>> 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
