[APIM][C5] Removing "Blocked" state from API lifecycle

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[APIM][C5] Removing "Blocked" state from API lifecycle

Yasima Dewmini
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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Nirmal Fernando-3


On Wed, May 17, 2017 at 11:50 AM, Yasima Dewmini <[hidden email]> 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.

Aren't those work-arounds? I think users would prefer to have a single place to block further invocations/subscriptions of an API. 

Please share your thoughts on this.

Regards,
Yasima.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Thanks & regards,
Nirmal

Technical Lead, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Nuwan Dias
In reply to this post by Yasima Dewmini
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.

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 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Sanjeewa Malalgoda


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : +94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Nuwan Dias
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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Lakshman Udayakantha
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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Lalaji Sureshika
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Yasima Dewmini
In reply to this post by Lakshman Udayakantha


On Thu, May 18, 2017 at 3:44 PM, Lakshman Udayakantha <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Software Engineer, WSO2, Inc.
Mobile: +94713117081

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Nuwan Dias
In reply to this post by Lalaji Sureshika
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Ishara Cooray
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Nuwan Dias
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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: 0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Sanjeewa Malalgoda
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 <[hidden email]> 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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : +94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

lakmal Warusawithana
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.

On Fri, May 19, 2017 at 6:37 PM, Sanjeewa Malalgoda <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Shani Ranasinghe
Hi,

On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana <[hidden email]> 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.

On Fri, May 19, 2017 at 6:37 PM, Sanjeewa Malalgoda <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
If we do it this way, would it impact any stats?
 

On Thu, May 18, 2017 at 12:06 PM, Sanjeewa Malalgoda <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks and Regards,
Shani Ranasinghe

Senior Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 77 2273555
linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Sanjeewa Malalgoda
In reply to this post by lakmal Warusawithana


On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : +94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Gayan Gunarathne


On Mon, May 22, 2017 at 10:59 AM, Sanjeewa Malalgoda <[hidden email]> wrote:


On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Gayan Gunarathne
Technical Lead, WSO2 Inc. (http://wso2.com)
Committer & PMC Member, Apache Stratos
email : [hidden email]  
 
 

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM][C5] Removing "Blocked" state from API lifecycle

Yasima Dewmini
Hi All,

Thanks for the feedback.
According to the offline discussion had with NuwanD, Sanjeewa and Lakmal, we decided to rename "Blocked" state to "Maintenance" state preserving the functionality.

@Shani
With this decision, it will not affect any stats in APIM.

@Gayan
This will not affect the functionality of subscription blocking or throttle level blocking since they have separate blocking implementation which is independent from API blocking.

Regards,
Yasima.

On Tue, May 23, 2017 at 10:29 AM, Gayan Gunarathne <[hidden email]> wrote:


On Mon, May 22, 2017 at 10:59 AM, Sanjeewa Malalgoda <[hidden email]> wrote:


On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 : <a href="tel:+94%2077%20262%209512" value="+94772629512" target="_blank">+9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

On Fri, May 19, 2017 at 9:49 AM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias <[hidden email]> 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 <[hidden email]> 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.

--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081



--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/





--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakshman Udayakantha
WSO2 Inc. www.wso2.com
lean.enterprise.middleware
Mobile: <a href="tel:071%20742%209601" value="+94717429601" target="_blank">0717429601


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lalaji Sureshika
WSO2, Inc.;  http://wso2.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Gayan Gunarathne
Technical Lead, WSO2 Inc. (http://wso2.com)
Committer & PMC Member, Apache Stratos
email : [hidden email]  
 
 

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Software Engineer, WSO2, Inc.
Mobile: <a href="tel:+94%2071%20311%207081" value="+94713117081" target="_blank">+94713117081

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture