[PSR-7] Http Client Interface

[Barry vd. Heuvel]

Hello all,

Thank you for creating and accepting PSR-7. I tried using the Request/Response interfaces in some project, but it feels like the Interface for HTTP Clients (Like Guzzle, Buzz etc) is missing. Probably because this was out of the scope for PSR-7.

I found this project: https://github.com/beberlei/http-client-middleware with the fitting description:

Missing interfaces for HTTP-Client middlewares using PSR-7 messages.

 Which indeed provides the functionality I'm looking for; a simple interface to make a execute a PSR-7 Request and return a PSR-7 Response. This way, I don't have to rely on Guzzle/Buzz/etc directly.

Example from the project:

interface ClientInterface
{
    /**
     * @param \Psr\Http\Message\RequestInterface $request
     * @param array $options - Vendor-specific options, don't rely on for interop.
     *
     * @return \Psr\Http\Message\ResponseInterface
     */
    public function send(RequestInterface $request, array $options = []);
}

Would this be something the PHP-FIG is interested in following up on? I do appreciate the initiative from @beberlei to create this, but of course an 'official' set of interfaces would be more likely to be widely adopted.

Example use-case would be something like Omnipay, that needs to make GET/POST requests and handle responses. While the Request + Responses could be based upon PSR-7 already, for the actual http client, the implementation is bound to a specific http library.

It would be pretty trivial to create a GuzzleAdapter, BuzzAdapter, CurlAdapter etc, but that kind of defeats the purpose again (as every project is going to create it's own wrapper, unless 1 accepted standard is agreed upon).

Thanks!

Barry vd. Heuvel

[Glenn Eggleton]

Guzzle is already working on a PSR-7 implementation.

https://github.com/guzzle/psr7

Would this not cover your use case?

Glenn

[Barry vd. Heuvel]

Guzzle does cover the Request/Response flow, but this does tie the implementation to Guzzle, instead of a 'http client interface'.
The project by @beberlei is based upon the Guzzle ClientInterface actually.

Op maandag 15 juni 2015 15:29:06 UTC+2 schreef Glenn Eggleton:

[Márk Sági-Kazár]

Hey,

Barry, I don't think any common HTTP client interface will be implemented in the near future by all major HTTP clients.

I suggest taking a look at https://github.com/php-http/adapter which is the contract package for adapters for all major HTTP clients.

(Full disclosure: I am one of the authors)

Cheers,
Mark

[Luis Pabón]

Hello,

I also feel the client interface is missing, otherwise you're creating a hard dependency on your application to a specific HTTP client such as guzzle, instead of fully relying on abstraction. This makes swapping HTTP clients very difficult indeed.

Guzzle's ClientInterface is good, all methods within already rely on PSR-7 interfaces instead of Guzzle's own.

What's the justification for not including a client interface to begin with?

Regards,

Luis

[Matthew Weier O'Phinney]

On Aug 7, 2015 5:09 AM, "Luis Pabón" <cop...@gmail.com> wrote:
>
> Hello,
>
> I also feel the client interface is missing, otherwise you're creating a hard dependency on your application to a specific HTTP client such as guzzle, instead of fully relying on abstraction. This makes swapping HTTP clients very difficult indeed.
>
> Guzzle's ClientInterface is good, all methods within already rely on PSR-7 interfaces instead of Guzzle's own.
>
> What's the justification for not including a client interface to begin with?

A client interface required message abstractions, and we felt these were sufficiently complex to warrant their own standard. Additionally, those messages can be consumed not just by clients, but server-side applications; including a client interface would have had the unfortunate side-effect of suggesting they were only targeting http clients, and limited adoption.

If you would like to see a standard around clients, I suggest proposing one. Now that PSR-7 is in place, it should be much less complex and easier to get consensus.

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/96e68df8-c05c-44d5-a579-ae134f904fa2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.