The problem with dumping all of the error handling and redirection logic into
the client itself is that it presumes what you want that error handling and
redirection logic to be.
If a response comes back with a 301 Moved Permanently, I may want to know that
so I can update my own records (eg, a URL is stored in a DB somewhere). If
the client automatically follows the redirect then I don't know to do so.
Similarly, an indexer script doesn't want a 404 to generate an exception. It
expects a large percentage of its responses to be 404s, and exceptions are
super expensive. It would want to simply record that a 404 happened and keep
on going.
In either case, the proper way to handle it is to have an HTTP client
implementation that does what the spec says and just pass back the response,
whatever it is, and then compose various error handling implementations around
it. So you could easily wrap a "just follow redirects and don't bother
telling me" object around the actual client, or a "turn 4xx responses into
exceptions" wrapper, etc. There's probably some generic ones that could be
built or just write one for your application (that auto-updates your URL
database for redirects, for instance).
The question then is how to word the spec such that such wrapper
implementations of the interface are not technically spec violating, even
though they're the correct approach.
--Larry Garfield
On Friday, March 30, 2018 9:16:23 AM CDT Tobion wrote:
> 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
