The ML team has been experimenting with the API Gateway during the past months, and we ended up exposing all our model servers:

https://api.wikimedia.org/wiki/Lift_Wing_API

The main reasons why we need an API Gateway are:

1. Common place where to expose APIs, together with documentation standards etc..
2. Leverage Authentication and Authorization

The first bit is covered by the API Portal, we like its structure and we have been editing our pages up to now very easily. The second point has been more complicated to manage, since the OAuth support in the API Gateway seems to be still missing some features.

Ideally we'd like to have the following use cases covered:

• Authenticated users should be able to be distinguished and there should be a quick way to either ban or heavily rate limit a specific logged in user (like an aggressive bot for example).
• Rate limits for Authenticated users should be enforced by the API Gateway using the settings that administrators add.
• It would be nice to be able to authorize only some groups of logged in users to access certain parts of an API (for example, say that we run a model server with private data that we'd like to avoid exposing to the public for security concerns).

The rate limits are the most visible pain point, since if an OAuthed client holds a bearer token with a rate limit class in it, that takes the priority completely over what we specify on the API Gateway (so we don't have control on it during emergency situations etc...). For example: if a client gets a bearer token (after logging in correctly via OAuth) containing a rate limit of 100k requests/hour, what we set on the API Gateway for the same client is not considered and applied (say a lower threshold for reason X).

At the current stage, the ML team can only use Requestctl to limit traffic in emergency situations, bypassing completely the API Gateway.

For the moment, my proposal is to do the following:

• Keep Lift Wing on the API Gateway, so we have a good/big use case to work on.
• Raise the anonymous access traffic lifting up rate limits (currently, 10k requests/hour) and suggest users to avoid the OAuth part unless they want to test it.
• Work with API Platform and Service Ops to have a clear roadmap and path towards a future version of the API Gateway.

Does it sound good?