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 fu
On Mon, May 22, 2017 at 10:59 AM, Sanjeewa Malalgoda
wrote:
>
>
> On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana
> 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
On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana
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 shou
Hi,
On Fri, May 19, 2017 at 8:41 PM, Lakmal Warusawithana
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
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.
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 sim
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
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
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 L
On Thu, May 18, 2017 at 3:44 PM, Lakshman Udayakantha
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
> c
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
c
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, Nu
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
wrote:
>
>
> On Wed, May 17, 2017 at 12
On Wed, May 17, 2017 at 12:03 PM, Nuwan Dias 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
disabl
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
On Wed, May 17, 2017 at 11:50 AM, Yasima Dewmini 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
> temporar
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. B
17 matches
Mail list logo
