Ability to configure the client by service id.

[SofHad]

I think it is very interesting to have ability to configure a client by service id.
(Using a proxy class for example )

csa_guzzle:
    clients:
        github_api:
            service: my_client.service
            config:
                base_url: https://api.github.com
                defaults:
                    headers:
                        Accept: application/vnd.github.v3+json

(I can work on)

[csarrazi]

It's actually already possible to do this, and it is documented in the client configuration documentation page.

csa_guzzle:
    clients:
        github_api:
            alias: my_client.service
            config:
                base_url: https://api.github.com
                defaults:
                    headers:
                        Accept: application/vnd.github.v3+json

😉

[csarrazi]

Oh, you actually meant being able to specify an existing service defined somewhere else, and configure it using the bundle, right?

[SofHad]

Yes 👍
In case I would overload the configuration for client with constructor.

[csarrazi]

Hum, right now, you can already override the class, if needed, by providing the class argument in your client's configuration. But yes, it could be interesting.

csa_guzzle:
    clients:
        github_api:
            class: My\Bundle\Client
            config:
                base_url: https://api.github.com
                defaults:
                    headers:
                        Accept: application/vnd.github.v3+json

[SofHad]

the idea is, to merge the configuration coming from '_csa_guzzle_' with the Client constructor arguments.

[csarrazi]

Hum, this will be complicated, and it may prove difficult to prevent BC on such a feature.

I would suggest to take the problem by the other side, by using a compiler pass to extend the original guzzle service, instead, adding additional arguments, method calls, etc.
Or decorating the Guzzle service with your own service, which is done by most implementors.

The problem with such a feature is that it may prevent us from implementing other features which I very much want here, like a param converter to inject a response from an API call, and serialization.

For this, we need to make sure that the client actually returns what is expected, which is a PSR-7 response or request, or a promise, depending depending on the method being called.

[SofHad]

I thought of a proxy class with a magic method __call ?

[SofHad]

Or using https://github.com/Ocramius/ProxyManager ?

[csarrazi]

Possible. But in that case, I would actually inject the configured API client, instead. :)

[csarrazi]

But regardless, why not!

[SofHad]

ping @Arthurhall

[csarrazi]

Any news on this? :)

[SofHad]

I didn't have time to work on it :)

I would suggest to take the problem by the other side, by using a compiler pass to extend the original guzzle service, instead, adding additional arguments, method calls, etc.
Or decorating the Guzzle service with your own service, which is done by most implementors.

Config example:

# config.yml
csa_guzzle:
    clients:
        github_api:
            config:
                service: foo.client
                base_url: https://api.github.com
                overwrite: true  # whether overwrite the MyClient config
                defaults:
                    proxy: foo
                    headers:
                        Accept: application/vnd.github.v3+json

services:
    foo.client:
        class: Acme\AppBundle\MyClient
        arguments: [{proxy: bar}, @baz, %foo.param%]
        public: true

I don't see how to merge both configurations using the compiler pass?
I see 2 solutions, doing this with Middleware (override the Request configuration) or using the proxy design pattern ?