search

php-http / fig-standards

Standards either proposed or approved by the Framework Interop Group
http://www.php-fig.org/
Other
3 stars 2 forks source link

Client substitution #36

Open sagikazarmark opened 7 years ago

sagikazarmark commented 7 years ago

I opened a separate issue for this question because this keeps coming back.

I read the phrase "consistent behaviour" a few times in the issue tracker. While I agree that the interface implementor's behaviour needs to be consistent, the fact that clients can be configured otherwise proved to be a feature in the past.

Does it break the contract (eg. in case of the exception throwing thing)? Yes, it does. But I don't remember receiving any bug reports about having a misconfigured Guzzle client throwing exceptions.

Same for redirections.

Stating that clients by default (mean: with the default configuration) should follow the contract proved to be working (see Guzzle and HTTPlug). While I understand that a PSR needs to be perfect and everything, the reason why we submitted the PSR more than a year after HTTPlug was released is that gain some experience about what works and what does not.

As far as I can see, currently the approach in consuming libraries is the following: they expect any kind of HTTP clients to be injected which follows the contract, then they internally wrap it with a PluginClient which adds all kinds of magic to the HTTP flow.

Does it break the contract? The plugin client does, the injected client does not. Does it work? I believe it does.

Once again: I am all for being consistent in the contract and the PSR, but we keep real life use cases in mind.

kelunik commented 7 years ago

I think the goals should explicitly state that it's meant to be a low-level client that might be decorated for ease of use.

dbu commented 7 years ago

for e.g. guzzle that could mean to split it into a PSR low-level client and the actual guzzle client. and when you write a reusable library, you ask for the low-level client rather than the less strict guzzle client (that e.g. follows redirects and can throw exceptions).

sagikazarmark commented 7 years ago

I don't see how decoration make things easier instead of just supporting these features via configuration. Ultimately you would still want to rely on the interface in your code.