Jump to content

REST Gateway

From Wikitech

The REST Gateway is an Envoy instance for proxying and rewriting requests that would have previously gone to RESTBase as part of our migration away from the platform. It is a subconfiguration of the API Gateway chart. It runs as a Kubernetes service and is accessible via https://rest-gateway.discovery.wmnet:4113/.

For metrics see the API and REST Gateway dashboard.

What is the REST Gateway for?

The REST Gateway was initially built for the management external calls to RESTBase APIs as they migrated out of the service, preserving URL rewrites and header configuration in a similar manner to RESTBase for consistency. Additional APIs have since been added to the gateway and the gateway will ultimately serve as a central management point for external requests to most APIs at the foundation, providing monitoring, enabling versioning and enabling other features as they are released.

What is the REST Gateway not for?

The REST Gateway is not designed to be called internally except for testing purposes. Internal service to service requests should not use the REST Gateway's internal hostname (or make requests to the rest-gateway via the service mesh), and should explicitly use the service name and request pattern used by the service in question.

Services currently supported

The following is a non-exhaustive list of services where traffic is routed via the REST gateway (and so avoid use of RESTBase):

For an authoritative list of services/URLs served by the REST Gateway, see the ATS redirection script's configuration file.

Gateway configuration

Per-service configuration and traffic routing

The service configuration should be queried for the most up to date list of proxied services. These services are configured in the gateway but may not be configured to route public traffic, verify this by checking Puppet. The gateway-checkLua script configured on ATS instances checks request paths for /rest_v1/ URLs and, if they are in the config, route the requests to the configured gateway.

Headers

The REST Gateway automatically adds a set of headers to all responses as part of the RESTBase compatibility layer. See git for an up to date list. The REST Gateway will also add a content-security-policy header only if the header is absent.

Rate Limiting

Rate limiting for the REST gateway is being implemented in FY 2025/2026 (T399291). As of February 2026 it is still in in dry run mode (aka "shadow mode"). Enforcement is scheduled in two phases for early March and early April, see Wikimedia_APIs/Rate_limits#Rollout.

For metrics see the REST Gateway Rate Limits dashboard. Note that this dashboard reflects the state periodically gathered from Redis by redioscope.

See REST Gateway/Rate limiting for details.

Acceptance criteria

For a service to be routed to via the rest-gateway, certain criteria should be met before routing public traffic:

  • The service must have a discovery DNS record configured ($service.discovery.wmnet)
  • The service must be running in both eqiad and codfw
  • The service must emit either an etag or last-modified header
  • The service must emit a cache-control header

If a URL is being migrated from one service to another, the headers should match as closely as is reasonable with particular attention paid to the above.

Testing

The REST Gateway can be reached directly from inside the infrastructure. For instance, to query wikifeeds availability path:

curl -v -H 'de.wikipedia.org' https://rest-gateway.discovery.wmnet:4113/de.wikipedia.org/v1/feed/availability
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=REST_Gateway&oldid=2382908"