[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.

[wing328]

@jimmypuckett https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/resources/php/ApiClient.mustache is a good starting point. As you can see, it's still using cURL. Ideally one can replace it with another ApiClient.mustache that uses guzzle or HTTPlug, which already supports a range of adapters including Guzzle 5 and 6.

[baartosz]

I am working on it. Httplug looks like reasonable choice. I'll also use https://packagist.org/packages/guzzlehttp/psr7 for implementations of psr interfaces (Request, Response, etc).
Its big one so it will take some time.

[wing328]

Thanks @baartosz

If you need any help (e.g. testing) from the community, please let us know.

[baartosz]

@wing328 how are authentication methods usually tested? I can't really find anything in any of clients test suites.

[wing328]

@baartosz We do have some security definitions defined covering HTTP basic, API key, OAuth in the fake petstore spec: https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/test/resources/2_0/petstore-with-fake-endpoints-models-for-testing.yaml#L784

If you're looking for real endpoints that validates authentication setting, then we don't that at the moment.

Our long time goal is to leverage one of the server stub generator to generate server side code with edge cases that are not covered by the Petstore server.

[wing328]

HI everyone, @baartosz has filed #5190 to use httplug for PHP API client. Please give it a try and let us know if you've any feedback.

git checkout -b baartosz-php_httplug2 2.3.0
git pull https://github.com/baartosz/swagger-codegen.git php_httplug2

[Majkl578]

I too am interested in Guzzle 6.x+ support. To be honest, I've never heard of a library called HttpPlug so it's not really convincing for me to use - looking at the GitHub stars I'm probably not the only one.
I'd really prefer Guzzle rather yet another mystic library...

[baartosz]

Hello @Majkl578. In PR #5190 this matter was discussed and by default generated library will use Guzzle 6. Change is ready to review and test. Help would be appreciated.

[wing328]

PR by @baartosz merged into 2.3.0.