ability to enable/disable an API

[subnetmarco]

An use-case would be to quickly disable an API from being consumed.

[sonicaghi]

this is risky. you might want to add some security protection to this action.

[Tieske]

@sinzone Not really, anyone with access to this could just as well do a DELETE and cause the same outage.

[sonicaghi]

whats the difference then from having ACL plugin activated on a specific API?

[subnetmarco]

This operation deactivates the API immediately regardless of the plugins installed.

[pauldaustin]

Is anyone working on this?

If not I can create a pull request for one of the following two options.

1. Add a enabled boolean to the apis schema and in the resolver.lua have it send a HTTP_SERVICE_UNAVAILABLE (503) response. This would be my preferred approach as you can create the api and disable it at the same time until it is fully configured.

2. Implement an api_enabled plugin that would have an enabled boolean field. If enabled == false then it would send a HTTP_SERVICE_UNAVAILABLE (503) response.

My current work around is to create my API with a dummy upstream URL (e.g. http://localhost/error/503) and then after all the plugins are configured I change it to the real upstream url.

[Tieske]

there are two things here; available and enabled.

• enabled says the api is or isn't there. It would make a request fallback on another matching (but lower ranking) api if it was available. Basically the same behaviour as if the api simply wasn't there.
• available means it matches, is there, but gets blocked from access with a 503. No fallback on other apis.

available
Most efficient would be to have a plugin. It should not have a setting. Because when you add the plugin with available=true the plugin still causes overhead. The better approach would be to have a plugin that always returns a 503. The sheer fact that the plugin is added on an api, is then the marker for the api being unavailable. Possible configuration could be a specific message?
btw; this plugin should have the highest possible priority, such that it is always executed first

enabled
An enabled boolean should be added to the api entity, an api with this set should be skipped when loading the configuration (as if it doesn't exist), automatically making requests fall back on another api (if there is one).

Does this make sense?

[pauldaustin]

That sounds reasonable. I can work on a pull request if you'd like.

[Tieske]

a PR would be nice 👍

just for reference linking this to #1725 same, but on consumers.

[pauldaustin]

I'm splitting this into a few PR's.

The first Http Response 503 Service Unavailable just adds a new response code for 503 Service Unavailable.

I wanted that separate to make sure I follow your committing process correctly before I do the next one which will be the api-unnailable plugin.

Let me know if I missed anything or should do anything different.

P. S. I did try and run the test suite but there seems to be some errors on the next branch. I did verify that this change didn't cause an error in normal operation of the server.

[Tieske]

👍

another thought; maybe the plugin should be configurable as in "request termination" plugin, with a configurable statuscode and message. Those could then default to "503" and "Service unavailable". But would allow for another status/message. (but feel free to stick to just 503)

I wanted that separate to make sure I follow your committing process correctly before I do the next one which will be the api-unnailable plugin.

just to be clear; this cannot be a plugin, this is part of the core.

[pauldaustin]

I was thinking along the same lines last night that it would be useful to be able to specify different status codes. You're last comment about being part of the core. For the enabled flag I was thinking that would be on the apis table and when the request is processed the api will be ignored by the core if enabled=false. For the request termination (was originally suggested as api unavailable) plugin that would be a core plugin in the core kong source tree with a high priority that would send the configured status code and message.

[p0pr0ck5]

This was done in #2328, no?

[pauldaustin]

Robert, No that pull request was for a plugin that allowed you to send a alternate HTTP status code instead of forwarding the request. The ability to disable an API was thought of at the same time. Except that disabling the API would skip it in the request processing. This allowing potentially another API to be matched. In effect it would be as if the API didn't exist but you could preserve the config if you wanted to enable it again. That could be useful in provisioning an API with a lot of plugins. Create it disabled, add the plugins then enable it.