I've reviewed the current doc and there are two points I highly disagree with and that does not seem to fit common use-cases.
1. The spec says, implementation must not follow redirects. This means any user of those interfaces must re-implement redirections themselves? I don't see how this default behavior is the desired behavior for almost all use-cases. The meta doc says "All clients communicating to an external API use some form of HTTP client.". But redirects are common in HTTP and APIs. So every package relying on these standard interfaces is basically broken and does not support redirects unless they handle them manually? 2. The spec says error responses do not result in exceptions. From my experience this is also very bad for most cases. Basically the only case where you don't care about the response code is if you write a proxy. Other than that you will need to check the response code for every response you get. What I've seen alot, is people doing stuff like `if ($response->getStatusCode() !== 200) handleError()`. But that does not work as soon as you receive a 201 for example. As you can see properly checking for error responses is not super straight forward. And PSR-7 does not define a method like `$response->isErrorCode`. So people either need to implement that themselves. Or rely on packages providing helper methods for things like that like guzzle/psr7. But then it undermines the goal of the PSR to avoid version conflicts and avoid concrete implementations. If sendRequests throws exceptions for error responses, people do not need to implement checking for error respones at least as that is handled by the implementation. And in most cases the workflow for error respones is different than for success ones (retrying, logging, aborting etc.). So handling that with exceptions is more natural and logical to me. Am Freitag, 16. März 2018 17:58:56 UTC+1 schrieb Tobias Nyholm: > > > Thank you Luis for the feedback. Here are some short answers: > > * Regarding async: See the meta document: > https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client-meta.md > * Method signature: We want to make sure that major libraries could > implement this interface without breaking BC. > * Regarding exceptions' verbosity: See the meta document > * Exceptions is thrown when there is no response. =) > > See the meta document and the current specification. Most of your ideas > has been visited already. > > > https://github.com/php-fig/fig-standards/blob/master/proposed/http-client/http-client.md > > > Den fredag 16 mars 2018 kl. 17:24:07 UTC+1 skrev Luis Pabón: >> >> My 2p: >> >> >> - This PSR needs async, otherwise there's not much value on it - I'd >> recommend following closely what guzzle is already doing >> - sendRequest is redundant. public function send(RequestInterface >> $request): Response >> - Exceptions should be way more verbose: need BadRequestException, >> ConflictException, TimeoutException, UnauthorisedException etc to >> accurately error-handle without boilerplate (eg checking status code). >> - Exceptions must also give access to the response as well as the >> HTTP status code separately >> >> >> On Sunday, February 25, 2018 at 7:00:40 PM UTC, Barry vd. Heuvel wrote: >>> >>> Good to hear it was just a typo :) >>> >>> > The specification looks good, we are currently deciding on an upgrade >>> path from HTTPlug. We have a proposal that we think will work. >>> >>> Does that mean the interface is likely to remain the same? >>> >>> I'm currently working on an upgrade for Omnipay from Guzzle to >>> (hopefully) PSR-18 (current work in progress is also based on HTTplug), >>> hence this PSR :) >>> >>> Op maandag 19 februari 2018 22:51:50 UTC+1 schreef Alessandro Lai: >>>> >>>> As per our bylaws (see >>>> https://www.php-fig.org/bylaws/psr-workflow/#abandoned), abandonment >>>> must be explicitly declared either by an abandonment vote, or by a >>>> secretary, but with some prerequisites: >>>> >>>> - missing editor or sponsor for more than 60 days (not the case here) >>>> - no activity in 6 months (not the case either, see commits on draft: >>>> https://github.com/php-fig/fig-standards/commits/master/proposed/http-client >>>> ) >>>> >>>> So yes, PSR-18 is not abandoned but in draft stage, as correctly stated >>>> in our repo/site: https://www.php-fig.org/psr/#draft >>>> >>>> Il giorno domenica 18 febbraio 2018 12:28:18 UTC+1, Stefano Torresi ha >>>> scritto: >>>>> >>>>> As far as I know, PSR-18 has never been marked as abandoned, I don't >>>>> even think the requirements to do so have ever been satisfied. Could the >>>>> secretaries confirm, please? >>>>> >>>>> Il giorno gio 15 feb 2018 alle ore 08:47 Tobias Nyholm < >>>>> tobias...@gmail.com> ha scritto: >>>>> >>>>>> Yeah, it has stalled for a few weeks. but we are working on it again. >>>>>> The specification looks good, we are currently deciding on an upgrade >>>>>> path >>>>>> from HTTPlug. We have a proposal that we think will work. I've invited a >>>>>> few to have a look on it (Sara included). If this small group think it >>>>>> is >>>>>> fine I will publish it so every one could give their comments. >>>>>> >>>>>> If no major issues are found I will move the PSR to review. >>>>>> >>>>>> Den onsdag 14 februari 2018 kl. 13:11:46 UTC+1 skrev Barry vd. Heuvel: >>>>>>> >>>>>>> Apologies, I now see that PSR-18 is referenced in the Sunshine >>>>>>> meetings ( >>>>>>> https://groups.google.com/forum/#!topic/php-fig/sjASl6ltjHI ) >>>>>>>> >>>>>>>> >>>>>>>> PSR - 18 HTTP Client (*Abandoned*) >>>>>>>> >>>>>>>> - Tobias identified an issue and will be notifying the group to >>>>>>>> source needed changes. >>>>>>>> - Tobias is waiting on *Sara to offer feedback*. >>>>>>>> - This PSR needs 2 implementations to move forward. >>>>>>>> >>>>>>>> Status abandoned, is that supposed to be Draft? As you are >>>>>>> discussing the issue with the group. Or are you in search of a new >>>>>>> Editor? >>>>>>> >>>>>>> -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8fe05aa5-bd2c-4ee5-bcba-58eeefde709e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
