Create initial proxy service

[emilyatmobtown]

This PR creates the basic structure for the library. The package can be installed to a project and, when enabled on a request by filter, will take over the dispatch of a WP_REST_Server request. In this way, a WP REST API endpoint can be used to proxy a request to a remote API.

[dlh01]

This is a pretty interesting approach. I'd love to know more about the situation that led to it.

I think my biggest question is about the use of the rest_pre_dispatch filter, since it necessitates re-implementing the logic for matching the route and everything that follows. Would it work to use the rest_dispatch_request filter? That runs after after the core REST server finds the handler and checks the request params.

[emilyatmobtown]

This is a pretty interesting approach. I'd love to know more about the situation that led to it.

I think my biggest question is about the use of the rest_pre_dispatch filter, since it necessitates re-implementing the logic for matching the route and everything that follows. Would it work to use the rest_dispatch_request filter? That runs after after the core REST server finds the handler and checks the request params.

@dlh01 I hear you – I weighed that option as well. Going that route would require having a callable callback in the route registration. Otherwise dispatch() returns an error before the rest_dispatch_request filter is called.

By hijacking the request earlier, the callback property still needs to exist in the route registration args for a handler to be matched, but it can be an empty string. That felt like an acceptable requirement in integrating the library. Requiring a throwaway callback felt awkward.

The situation that led to it is an API using WP REST API endpoints that is a proxy for requests to a remote API. The remote API is the source of truth for data, but is not built to handle the kind of traffic that will come from the site. The proxy will leverage edge cache and object cache to reduce the traffic and also integrate data points from WordPress in the response so the remote response can be trimmed down.

[dlh01]

By hijacking the request earlier, the callback property still needs to exist in the route registration args for a handler to be matched, but it can be an empty string. That felt like an acceptable requirement in integrating the library. Requiring a throwaway callback felt awkward.

Huh. I guess I understand that point, but why would the route not have a callback?

Maybe I misunderstood something. I thought that this library was for intercepting requests to routes that would otherwise have been served by WordPress. Is the idea instead that implementers would register a route with the intention of having the route be served by this library? So your route registration would be lighter-weight, and then by integrating the route with the plugin, the plugin would do most of the work behind the scenes?

[emilyatmobtown]

Huh. I guess I understand that point, but why would the route not have a callback?

Maybe I misunderstood something. I thought that this library was for intercepting requests to routes that would otherwise have been served by WordPress. Is the idea instead that implementers would register a route with the intention of having the route be served by this library? So your route registration would be lighter-weight, and then by integrating the route with the plugin, the plugin would do most of the work behind the scenes?

@dlh01 Exactly. The latter is the intention. The WordPress route is simply a proxy to a third party request. There may be other use cases, but in our case the third party API is not built for the volume of traffic on the site so we'll mitigate that with a caching layer in the proxy API. There's also a hook to add a transformation layer so while a callback isn't needed, there is the option of transforming the response shape in the implementation.