-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conventional way to configure client #85
Comments
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. |
I mostly agree with the things @dbu said. One addition (actually a highligh of something that is already mentioned): discoveries have two purposes:
|
And what about different option names of client or request? For example, Guzzle6 has an option |
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. |
In the context written above, I think that CurlHttpClient should just accept PHP cURL constants as options keys. |
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 [
'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 |
This may be solved in the particular framework adapter like https://github.com/php-http/HttplugBundle |
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. |
So, you think that it must be an application (or component/module/bundle) logic. I understand, thanks. |
Absolutely, this is the whole idea about httplug: rely on contract in reusable component, rely on actual implementation, config in the application. |
I think this issue can be closed. |
And another question: I can't use |
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. |
@RomeroMsk We are available on slack, you can ask for help there. Can I close this? |
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. |
Hm..sorry? 😛
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.
See this comment for the use cases of discoveries. |
Sorry, I've updated the comment =) |
Thank you, guys, now it is more clear for me! Of course, you can close the issue. |
I guess we will have to provide an example application to clear the confusion. Libraries using Httplug will be good examples as libraries. |
Exactly ;) |
after reading codes in I know I got a
so make a
and new it when use
|
@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. |
it is a reusable library. lib so I'm working on update its depend to yet without binding to guzzle6, I have no idea how to set options
these settings should be hidden for lib users ,so finally I do so. |
Adds a new discovery strategy to have discovery find the configured client.
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:
The text was updated successfully, but these errors were encountered: