A PSR-18 wrapper for the WordPress HTTP API.
usePsr\Http\Client\ClientExceptionInterface;
usePsr\Http\Message\RequestFactoryInterface;
usePsr\Http\Message\ResponseFactoryInterface;
useWpOop\HttpClient\Client;
/** @var RequestFactoryInterface $requestFactory *//** @var ResponseFactoryInterface $responseFactory */// Set up the client with WP request options// https://developer.wordpress.org/reference/classes/wp_http/request/$client = newClient(
// Default args to WP_Http::request()
[
'redirection' => 2,
'timeout' => 60,
],
$responseFactory,
// Path to proxy file dir to enable response streaming.// If null, will buffer in memory instead.get_temp_dir() );
// Create a PSR-7 request in any way you want, for example via a PSR-17 factory$request = $requestFactory->createRequest('GET', 'http://somesite.com/api');
try {
// Send a request as usual, consuming a familiar PSR-18 interface$response = $client->sendRequest($request);
} catch (ClientExceptionInterface$e) {
// Handle PSR-18 exceptions
}Since this is a PSR-18-compliant implementation, you can consume it in the way you would any other.
To set it up, pass a map of WP request options, and a PSR-17 response factory. This approach facilitates decoupling from any concrete PSR-7 implementation.
You can use any PSR-17 implementation or PSR-7 implementations. I suggest the slim and efficient nyholm/psr7, which conveniently implements both.
Currently only throws ClientExceptionInterface, as it is unable to reliably determine whether a network or
another specific kind of problem has occurred from the error value returned by wp_remote_request().