Comments (23)
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.
from httplug.
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
from httplug.
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?
from httplug.
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.
from httplug.
In the context written above, I think that CurlHttpClient should just accept PHP cURL constants as options keys.
from httplug.
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
?
from httplug.
This may be solved in the particular framework adapter like https://github.com/php-http/HttplugBundle
from httplug.
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.
from httplug.
So, you think that it must be an application (or component/module/bundle) logic. I understand, thanks.
from httplug.
Absolutely, this is the whole idea about httplug: rely on contract in reusable component, rely on actual implementation, config in the application.
from httplug.
I think this issue can be closed.
from httplug.
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?
from httplug.
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.
from httplug.
@RomeroMsk We are available on slack, you can ask for help there. Can I close this?
from httplug.
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. =)
from httplug.
when writing a library and when writing a library.
Hm..sorry? 😛
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.
from httplug.
Sorry, I've updated the comment =)
from httplug.
Thank you, guys, now it is more clear for me! Of course, you can close the issue.
from httplug.
I guess we will have to provide an example application to clear the confusion. Libraries using Httplug will be good examples as libraries.
from httplug.
I guess we will have to provide an example application to clear the confusion. Libraries using Httplug will be good examples as libraries.
Exactly ;)
from httplug.
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);
from httplug.
@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.
from httplug.
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.
from httplug.
Related Issues (20)
- HttpFulfilledPromise constructor parameter should be mixed HOT 3
- Circuit Breaker HOT 6
- Missing badges HOT 2
- Sending file from a multipart stream HOT 13
- Add support for HTTP proxies and SSL Client certificates? HOT 7
- How to set timeout for a request while being abstracted from a HttpClient implementation? HOT 6
- Implementation Question: how to code Client options in a library-agnostic way? HOT 5
- Benchmarks? HOT 2
- Prepare version 2.0 HOT 6
- HMAC Authentication Plugin HOT 4
- phpstan complains about Http\Client\Exception HOT 6
- Adding deprecated HOT 5
- HttpException create method self vs static HOT 1
- Symfony HTTP Client Adapter HOT 1
- PSR-18: Network / Request exception inheritance HOT 1
- Add psr-18 github tag HOT 1
- Throwable not supported HOT 8
- State of async HTTP clients and promises HOT 13
- PHP 8.0 support HOT 1
- "php-http/httplug" package is not installed HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from httplug.