Support using different HTTP Clients through PSR-17 and PSR-18

[soullivaneuh]

As suggested on Twitter, I'm opening a new issue to ask reconsidering #538.

The pros of using http-plug:

• You don't need to handle the HTTP communication part. Just use the interface, php-http will handle the rest. Less code to write, you can now focus on oauth2 logic only.
• Happy end users (project developers) will not be locked to Guzzle v6 requirement. He can use any version he wants or an another library.
• Want to still use Guzzle 6? Guess what? You can! http://docs.php-http.org/en/latest/clients/guzzle6-adapter.html
• Bench of plugins can be used by both maintainers and end users. For example, the end users might want to log the requests thanks to this: http://docs.php-http.org/en/latest/plugins/logger.html

The con of using http-plug: Two more packages to add to the composer require command line. Not a big deal. Plus, a lot of users are already using php-http so they might not need that. 👍

Having the php-http implementation will be very valuable for this library.

Could you please reconsider the PR?

Please see also #538 (comment).

@Nyholm Are you ok to rebase your PR if accepted by the team?

Best regards.

[Nyholm]

I’ll be happy to.

[javiereguiluz]

@soullivaneuh I'd be happy if HTTP Plug is used ... but your list of pro/cons looks a bit biased :) Installing two more packages is the only drawback? No changes are needed anywhere? End users don't need to change anything? This Oauth client doesn't have to refactor any part of it or its tests? Docs don't need to be updated? etc.

[soullivaneuh]

End users don't need to change anything?

I don't think so, as the API calls are done by this library, not by the user. Am I wrong?

This Oauth client doesn't have to refactor any part of it or its tests?

Of course. I think all is done on #538. Maybe plugins will be affected, I'm not sure about the structure. But we can use deprecation for that.

Docs don't need to be updated?

Well, this is what I meat by "Two more packages ...". :-)

And it's already done on #538.

[soullivaneuh]

Another benefit of using php-http: The adapter can be a mock thanks to this: http://docs.php-http.org/en/latest/clients/mock-client.html

This make integration tests very much easier. 👍

[JaZo]

I really like to be able to use other HTTP clients. Since Guzzle 7 is now PSR-18 compliant I think it shouldn't be a really big change to realize this.

[ramsey]

Updated the title and added the "enhancement" label. Doing this would also solve #863, since we'd be allowing more customization of the HTTP client.

[burzum]

Any news on this? I really would like to use pure PSR interfaces and a small library, not that giant piece of code that Guzzle is that doesn't provide at least me any additional benefit other than it adds unwanted complexity.

[xvilo]

@ramsey I see that there are a couple of PRs linked to this issue, but they are closed. Due to the long discussions on them, I can't immediately figure out why this was not yet implemented. Can you add a description on why the previous attempts failed?

We would like to see this added, as we're currently integrating Guzzle as an extra dependency just because this library requires it. It would streamline internal processes of our development team if we can deal with 1 unified HTTP client implementation for everything. As for our case, we made decision to not use Guzzle if possible, but that's on us 😉

[tacman]

Great library, thanks for releasing it.

My applications all use the Symfony HttpClient, and I'd love for this oauth-client to use it instead of guzzle. The Symfony HttpClient integrated in the debug toolbar, less dependencies for the application, blah blah.

Happy to test if there's a branch.