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?

[Nyholm]

I can understand the confusion. It is not clear enough how it differs in usage of Httplug when writing a library and when writing an application.

@RomeroMsk When writing an application you should always know what client to use, you should instantiate it yourself and configure it as you want. The HttpClientDiscovery is used when writing a library. =)

[sagikazarmark]

when writing a library and when writing a library.

Hm..sorry? :stuck_out_tongue:

When writing a library you should always know what client to use, you should instantiate it yourself and configure it as you want.

When writting a library, you should accept an HttpClient which should be preconfigured. Inside your library, you don't need to know what client you have. It is only required at configuration time....in your application for example or in your test suite.

The HttpClientDiscovery is used when writing a library. =)

See this comment for the use cases of discoveries.

[Nyholm]

Sorry, I've updated the comment =)

[RomeroMsk]

Thank you, guys, now it is more clear for me! Of course, you can close the issue.

[sagikazarmark]

I guess we will have to provide an example application to clear the confusion. Libraries using Httplug will be good examples as libraries.

[RomeroMsk]

I guess we will have to provide an example application to clear the confusion. Libraries using Httplug will be good examples as libraries.

Exactly ;)

[php-cpm]

after reading codes in omnipay/omnipay-common:dev-master

I know I got a Client class to be extends:

use Http\Client\HttpClient;
use Http\Discovery\HttpClientDiscovery;
use Http\Discovery\MessageFactoryDiscovery;
use Http\Message\RequestFactory;

class Client implements HttpClient, RequestFactory
{
    /**
     * @var HttpClient
     */
    private $httpClient;

    /**
     * @var RequestFactory
     */
    private $requestFactory;

    public function __construct(HttpClient $httpClient = null, RequestFactory $requestFactory = null)
    {
        $this->httpClient = $httpClient ?: HttpClientDiscovery::find();
        $this->requestFactory = $requestFactory ?: MessageFactoryDiscovery::find();
    }
...
}

so make a MyClient class like this

use Omnipay\Common\Http\Client as HttpClient;
use Http\Adapter\Guzzle6\Client;

class MyClient extends Client
{
    public function __construct(array $config)
    {
        $client = Client::createWithConfig($config);
        parent::__construct($client);
    }
}

and new it when use

$this->httpClient = new GuzzleClient($options);

[dbu]

@php-cpm if this is about a reusable library, it should provide instructions how to configure the client, but not tie to guzzle6. if this is an application and you chose httplug with guzzle6-adapter, you can also simply pass an instance of the correctly configured GuzzleHttp\ClientInterface instance to the Http\Adapter\Guzzle6\Client constructor.

[php-cpm]

it is a reusable library.

lib lokielse/omnipay-wechatpay depends on omnipay/omnipay-common v2 which binds to guzzle3, too old

so I'm working on update its depend to omnipay/omnipay-common v3 which finds httpClient auto.

yet without binding to guzzle6, I have no idea how to set options

        $options = [
            'curl' => [
                CURLOPT_SSL_VERIFYPEER => true,
                CURLOPT_SSL_VERIFYHOST => 2,
                CURLOPT_SSLCERTTYPE    => 'PEM',
                CURLOPT_SSLKEYTYPE     => 'PEM',
                CURLOPT_SSLCERT        => $this->getCertPath(),
                CURLOPT_SSLKEY         => $this->getKeyPath(),
            ]
        ];

these settings should be hidden for lib users ,so finally I do so.