[PHP] update HTTP library to use Guzzle

[wing328]

We want to upgrade the HTTP library to use Guzzle, which is a very mature HTTP library with lots of features: https://github.com/guzzle/guzzle#guzzle-php-http-client

If you want to work on this and need help on where to start, please ping @wing328. Thanks!

[jimmypuckett]

@wing328, I think that this is a great idea, but I would think that the effort should wait on guzzle making guzzle-service working with guzzle 6. At that point, it would just be a matter of converting the swagger specs to guzzle services.

[wing328]

@jimmypuckett thanks for the tips. I'd a look at guzzle-service but couldn't find the spec it uses. I'll check with the owner to find out more about the service and its specification when the project becomes more mature.

[jimmypuckett]

@wing328, ya it is not well documented. It was very nice back in guzzle 3 days. I am looking forward in them releasing the update for version 6.

[kasperg]

How about using HTTPlug instead? This a client abstraction and thus we avoid binding the implementation to a single library.

HTTPlug already supports a range of adapters including Guzzle 5 and 6 as well a simple .

@wing328: If you agree with that direction I would be interested in taking a stab at this.

I think there is some value in the fact that the current ApiClient does not introduce further dependencies. One way to retain this value could also be to refactor the current ApiClient into an abstract ApiClient class and a CurlApiClient implementation . Then third party packages could provide HTTPlugApiClient, FrameworkXApiClient implementations etc.

[wing328]

@kasperg thanks for the suggestion to use HTTPlug.

As you suggested, creating an abstract class is one way to do it (which is perfectly fine with me but some developers may not want the dependency on HTTPlug)

Another way is to following Java's current approach to generate ApiClient file based on library specified. To apply that to PHP, you will need to create another file ApiClient.HTTPlug.mustache and use it (instead of the ApiClient.mustache in PHP) when users specify the library=HTTPlug option.

Which approach do you feel more comfortable implementing?

[kasperg]

I did not know about the library option but I think that is the way to go.

Having thought about third party packages with implementations will not work. The invokerPackage configuration option means that we cannot rely on a stable class name to extend.

[Babacooll]

Hi ! Do we have any update on the update to a newer version of Guzzle ? @wing328

[wing328]

@Babacooll I don't think anyone is working on that. Would you have time to contribute the update?

What features do you plan to use in the latest version of Guzzle (6.2.2)?

[Babacooll]

@wing328 I currently don't have time but I'll think about it.

It's mostly for security purposes as the version 3 has not received any security fixes for ages.

[richhl]

@wing328 guzzle 6 service is out there. We are interested in work on swagger client generation using guzzle 6 and guzzle service. do you have time too to work on this?. we will need help on where to start. do you have a gross estimation of how much it will take to us to implement this?

i have seen there is a library to translate openapi spec to guzzle service definition but the project seems to be dead https://github.com/loco/swizzle

thx in advance.