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? > Yes we have a customizable API lifecycle in C5. So, anyone wants to add a > state to lifecycle can import customized lifecycle and implement the logic. > It does not need a configuration to do that. > Thanks, Yasima. > > 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* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- http://wso2.com/signatureYasima Dewmini Software Engineer, WSO2, Inc. Email: [email protected] Mobile: +94713117081
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
