Change Details

One of the main goals behind moving to a [REST Content API](https://www.mediawiki.org/wiki/Requests_for_comment/Content_API) is enabling caching of API responses across the board. This will help us scale our APIs to keep up with growing demand, and lowers latency for clients by leveraging our geo-distributed caching infrastructure. RESTBase requests are already proxied through the regular text varnishes, but caching of responses is still disabled by setting headers to that effect. Before we can enable Varnish caching for RESTBase end points, we'll need to set up Varnish purging. The production logic for this lives in [HTCPPurge](https://github.com/wikimedia/mediawiki/blob/b79196778ed7c4f49ae09bee9ba16f861a6e3760/includes/deferred/SquidUpdate.php#L140-L233). The UDP logic itself doesn't look too hard. The config data referenced there is simple enough (one IP address & one TTL) to let us manually replicate it in the RESTBase config for now.

One of the main goals behind moving to a [REST Content API](https://www.mediawiki.org/wiki/Requests_for_comment/Content_API) is enabling caching of API responses across the board. This will help us scale our APIs to keep up with growing demand, and lowers latency for clients by leveraging our geo-distributed caching infrastructure. RESTBase requests are already proxied through the regular text varnishes, but caching of responses is still disabled by setting headers to that effect. Before we can allow Varnish to cache specific GET responses, we'll need to set up Varnish purging for those end points. The production logic for this lives in [HTCPPurge](https://github.com/wikimedia/mediawiki/blob/b79196778ed7c4f49ae09bee9ba16f861a6e3760/includes/deferred/SquidUpdate.php#L140-L233). The UDP logic itself doesn't look too hard. The config data referenced there is simple enough (one IP address & one TTL) to let us manually replicate it in the RESTBase config for now.

One of the main goals behind moving to a [REST Content API](https://www.mediawiki.org/wiki/Requests_for_comment/Content_API) is enabling caching of API responses across the board. This will help us scale our APIs to keep up with growing demand, and lowers latency for clients by leveraging our geo-distributed caching infrastructure. RESTBase requests are already proxied through the regular text varnishes, but caching of responses is still disabled by setting headers to that effect. Before we can enableallow Varnish to caching for RESTBase end pointse specific GET responses, we'll need to set up Varnish purging for those end points. The production logic for this lives in [HTCPPurge](https://github.com/wikimedia/mediawiki/blob/b79196778ed7c4f49ae09bee9ba16f861a6e3760/includes/deferred/SquidUpdate.php#L140-L233). The UDP logic itself doesn't look too hard. The config data referenced there is simple enough (one IP address & one TTL) to let us manually replicate it in the RESTBase config for now.