Conventional way to configure client

[mekras]

Httplug interfaces does not provide a way to configure client behaviour such as timeouts, SSL settings or other parameters that cannot be set in the RequestInterface.

For example. In dev environments we want our HTTP client to ignore SSL errors. But we can do this only when instantiating particular implementation. It has two disadvantages:

1. we can't use HttpClientDiscovery;
2. code, where the client is introduced through the interface, can't change these settings.

[dbu]

imho this is the responsibility of the bootstrapping code, not of code using a client.

there can also be some overlap between the plugins we offer for HTTPlug and features of the client used (guzzle or even curl can do some of the things the plugins can do). but often we will want to make them "dumb" to have control in the plugins. but this setup needs to be the job of either the adapter or the bootstrap code of an application. e.g. in symfony, there are elegant ways to do that.

the discovery is a highly opinionated way of doing things, looking like the thing laravel misnames "facade". dependency injection is much cleaner and more flexible.
but its possible to set the client that should be discovered manually. so the bootstrap code can configure the discovery to its liking, as long as its executed before discovery is triggered.

[sagikazarmark]

I mostly agree with the things @dbu said.

One addition (actually a highligh of something that is already mentioned): discoveries have two purposes:

• provide easy, zero-configuration client construction
• provide defaults

[RomeroMsk]

And what about different option names of client or request? For example, Guzzle6 has an option connect_timeout, but in CurlHttpClient it is named connection_timeout. How to abstract from client-specific option names?

[sagikazarmark]

Are you asking froma convenience point of view or a standardizing point of view?

Client configuration is always "manual", so as we said above, having a conventional way of doing it doesn't make much sense.

However it's a nice idea to have the same conventions for option names. It would cause less confusion.

Not sure if it is possible though, as I saw, some of the options are named after cURL variable names.

@mekras Could give a better insight.

[mekras]

In the context written above, I think that CurlHttpClient should just accept PHP cURL constants as options keys.

[RomeroMsk]

Are you asking froma convenience point of view or a standardizing point of view?

I'm just trying to understand, if and how I can make an universal configuration for client in my application. So if my app component is using Httplug with Guzzle6 adapter, I'm configuring the component with an array like this:

[
    'base_uri' => 'http://httpbin.org',
    'allow_redirects' => false,
    'connect_timeout' => 10,
    'timeout' => 30,
]

But when I'll decide to use another adapter, I will need to use something like this:

[
    'url' => 'http://httpbin.org',
    'redirects' => false,
    'connection_timeout' => 10,
    'response_timeout' => 30,
]

Maybe we need some kind of options adapter? Or add constants for common option names to Http\Client\HttpClient?

[mekras]

This may be solved in the particular framework adapter like https://github.com/php-http/HttplugBundle

[sagikazarmark]

We have already discussed this earlier and decided not including it in the contract. The possible number of options and ways to configure a client simply doesn't allow that.

If you decide to use another client, you should configure it, which is the only point where you know what client you use.

In a DI context this shouldn't be a hassle, like in the bundle @mekras linked.

[RomeroMsk]

So, you think that it must be an application (or component/module/bundle) logic. I understand, thanks.

[sagikazarmark]

Absolutely, this is the whole idea about httplug: rely on contract in reusable component, rely on actual implementation, config in the application.

[mekras]

I think this issue can be closed.

[RomeroMsk]

And another question: I can't use HttpClientDiscovery in this case, right? Because I don't see the way to configure Guzzle6 with HttpClientDiscovery. Maybe you can provide a sample code with Guzzle6 adapter?

[sagikazarmark]

No, you can't. If you need any configuration, you already have to know which client you use.

Discovery is a zero-knowlege, zero-configuration thing.

[sagikazarmark]

@RomeroMsk We are available on slack, you can ask for help there. Can I close this?