If we route the Action API through the central API gateway, we can begin consistently measuring traffic and usage patterns to gain insights that will inform future decisions and actions.

Background

Our KR focuses on migrating existing APIs to utilize common infrastructure, so that we may start driving commonalities across Wikimedia APIs and make it easier to monitor, maintain, and deliver API capabilities. The most critical piece of that infrastructure is introducing a universal API Gateway. Utilizing a common API gateway to serve, monitor, and control API access paves the way for more complex program needs, such as standardizing rate limits and authentication mechanisms. This gateway will take advantage of the existing API management gateway known internally as the REST gateway.

Problem statement
The Action API is our most heavily used API, powering thousands of community built bots and tools as well as key WMF owned features and extensions. Today, API controls such as rate limiting are implemented at the application layer and vary across specific modules. Additionally, although basic API monitoring is now in place, we lack more sophisticated tooling that could help us make better data driven decisions, particularly as it relates to comparing the Action API capabilities and utilization against other API families. While these problems are not directly solved by routing the endpoints through a common gateway, they are at least steps in the right direction to improve API observability and governance.

Impacted users
If done correctly, this work should have no impact on API users. Instead, it will provide benefits to API authors and owners by creating a centralized location to view API traffic and performance. Additionally, as we move towards standardizing API controls such as rate limiting and concurrency, API managers will have a single point to observe and enforce.

Scope

• Route Action API through the Common Gateway (fka: REST Gateway)
• Test and verify there is no impact on end users as the result of rerouting
• Iteratively dial up traffic per wiki group

Out of Scope

• Because there is effectively a single endpoint for the Action API, we are not performing an internal audit of the individual actions/modules.

Expected Outcomes

By routing the Action API through the Common Gateway, we will be able to improve consistency and observability.

Assumptions

• The Action API currently has no existing gateway; instead, traffic is handled on a dedicated cluster and simply passed through to the MediaWiki application. This means that it is unlikely that there is any custom request handling logic or header injections at the edge.

Known risks & limitations

• Because Action API usage is so pervasive, the impact of breaking it is high. However, we expect the risk of breakage to be very low, given the current architecture.

Related Work

WE5.2.2: Central Rerouting. In Q1, we completed work to reroute endpoints under the rest.php path. Future work will include continuing the rerouting effort across additional API families.

Dependencies

None

Next steps

This work only covers the Action APIs. Additional APIs, and particularly those served outside of MediaWiki, are still pending.

Deadline

Given the small scope, this work will ideally be completed by the end of November.