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