Why requiring Guzzle and not define an abstraction layer based on PSR7

[shulard]

Hello !

You are using a PSR7 compliant lib, Guzzle6.

I want to use your API wrapper in one of my project but my client require PHP5.4. With Guzzle6, you force the use of PHP5.5. I'll need to copy your rawCall method to use the same signature logic but in a new wrapper which match my requirements...

Are you aware of active developed tools to abstract HTTP layer ? Do you know Httplug ?

I you want, I can make a PR to integrate that kind of stuff. It allow more flexibility in the HTTP client used and avoid multiple clients in the same context...

Thanks !

[VincentCasse]

Hi @shulard,

First, thanks for your feedback!
We continue to maintain v1.x with Guzzle 5 to handle PHP 5.4+. You can use the v1.x branch or declare it directly into composer.

Httplug is quite young. I think the best is to wait and check if the project will be a standard in the PHP world or just a new idea not maintain.

If you have time to test Httplug, I'm open to this idea and contribute to the pull request.

Best regards,

[shulard]

Hi !

Thanks for your answer 😄

I viewed that 1.x is still on Guzzle 5 but is the 1.x sharing the same features as the 2.x ? Is it only a Guzzle update between the 2 versions ?

I think I'll make this PR. I know Httplug very well (I've developed the react adapter on it), it'll be a nice real case test of integration.

[VincentCasse]

Yes, v2 is only an update to guzzle 6 :) We need to add it into the documentation.

You are speaking about reactphp ? You are thinking that's possible to have multiple http requests in the same time with httplug?

[shulard]

Yes, I'm speaking about reactphp 😄.

Httplug handle synchronous and asynchronous requests natively. There is also adaptors for Guzzle5 and Guzzle6 and different clients (socket, curl) which handles the 2 requests types the same way.

[VincentCasse]

That's could be good :)
The must important is too have a simple solution for developers (no need to changes a lot of confs)

[shulard]

Yep for sure... I'll try to submit the PR during this week then we can review it and take the right decision.

For me, the most important here is that Ovh API will be used inside different project which, maybe, already rely on a HTTP Client. So load different client for the same need is too much code for me 😄.

I'll mention this issue in the PR to maintain discussion history.

Thanks