Supporting PSR-7 and PSR-18 for HTTP transport layer

[ezimuel]

We would like to support PSR-7 and PSR-18 for the HTTP transport layer. We was thinking to use HTTPlug in order to use an abstraction with some adapter implementations. As default adapter we can use CURL as we are already using it in the client. The idea is to release this with elasticsearch-php 8.0.

Any feedback? thanks!

[nicolas-grekas]

Since Symfony is a major ecosystem where this package is used, it'd be great to consider Symfony HttpClient also. Symfony HttpClient implements both http-plug and PSR-18, but also symfony/http-client-contracts.

The minimum way to play best with the ecosystem IMHO could be to not require any packages past the "contracts" ones - whichever of the 3 mentioned above is selected.

This way ppl would easily decide for the implementation they want to use - or benefit from the one wired by default in their ecosystem.

[nicolas-grekas]

Side note: symfony/http-client-contracts doesn't bring the complexity of dealing with PSR-7 + it's compatible with async and transport options (eg timeout). It might be a best default for this reason, as it would free users to deal with PSR-17 too (which is another thing required when using PSR-18) and find and wire an implementation, which is just a terrible experience with the PSR things IMHO...

[ezimuel]

@nicolas-grekas thanks for your feedback! We need to consider PSR-17 HTTP Factories in the list as well.
We'll also investigate the possibility to use Symfony HTTPClient. Can you point me to some async example use cases? Right now we are supporting async using future mode. I would like to see how Symfony has implemented this feature. Thanks!

[Nyholm]

I think that PSR-18 is a great idea for all libraries that are using HTTP... unless you need async.. =)

I would recommend HTTPlug of libraries that need async support. HTTPlug is PSR-18 + async. Yes, you need a PSR-17 implementation and maybe a way to provide zero configuration support. Using HTTPlug/PSR18 will maximise inoperability.

I do also believe that Symfony's HTTP client is the best PHP HTTP client. I recommend that it should be used in every application. It does provide adapters for HTTPlug so it is the only client you actually need to install.

I fear however that if a library would require only symfony/http-client-contracts it would be vendor lock-in. Because I believe that interface is quite difficult to implement differently than Symfony's two implementations.

[nicolas-grekas]

Sure, here are some examples:
https://github.com/dbrumann/sfughh-http-client-examples/tree/http_client/src/Command

The doc is also telling about it (tl;dr, responses are "lazy", they're comparable to "futures" in the current design):
https://symfony.com/doc/current/components/http_client.html

Check also:
https://speakerdeck.com/nicolasgrekas/symfony-httpclient-what-else

Basically, this sends requests in //:

$client = new \Symfony\Component\HttpClient\CurlHttpClient();

for ($i = 0; $i < 379; ++$i) {
    $uri = "https://http2.akamai.com/demo/tile-$i.png";
    $responses[] = $client->request('GET', $uri);
}

foreach ($responses as $response) {
    // do stuff
}   

The async interface of HTTPlug is also natively supported, it uses promises:

$client = new \Symfony\Component\HttpClient\HttplugClient();

for ($i = 0; $i < 379; ++$i) {
    $uri = "https://http2.akamai.com/demo/tile-$i.png";
    $responses[] = $client->sendAsyncRequest($client->createRequest('GET', $uri));
}

foreach ($responses as $response) {
    // do stuff
}

Note that HttplugClient implements both HTTPlug's async interface + the relevant parts of PSR-17. That's why we can call ->createRequest() on it.

[Nyholm]

The only reason that you may use Symfony's HTTP client and not HTTPlug is that you think the implementation will be much more simple to read, write and maintain.

Im not super familiar with the details of this library so I cannot say for sure how much easier it will be. Try =)

[Nyholm]

Btw, we will soon mark guzzlehttp/ringphp as abandoned on packagist.

[ezimuel]

@Nyholm yes, I know this is an outdated library. That's why we are moving on. Thanks for you feedback!

[thePanz]

That's great @ezimuel ! I quickly discussed with @dbu about this (he's one of the devs behind the HttPlug library), he is open for hints/reviews/help with this 👍

[ezimuel]

Thanks @thePanz and @dbu, I'll definitely ask for reviews.