Re: PSR for HTTP clients

[Fabien Bourigault]

I agree that exceptions throwing has to be explicitly defined. Anybody
would rely on an execution flow interruption that MAY happen. My preference
is to NEVER throw exception on 4xx/5xx as those are not exceptional. Those
are just valid HTTP responses like any other responses. I know some API
that use 409 (Conflict) as a normal execution flow. As an example, the
Gitlab API return this one when you try to add a user to a group he already
belongs to.
As a conclusion, I think the only exception a client can throw are
NetworkExceptions as anybody expect the network to fail in his application,
so it's an exceptional case.

Le lun. 4 sept. 2017 à 02:13, Sara Golemon  a écrit :

> On Friday, August 25, 2017 at 4:10:06 AM UTC-4, Barry vd. Heuvel wrote:
>>
>> So given the unanimous support for the HTTP Client and the current
>> implementations, the only actual point of discussion is the throwing of
>> Exceptions on 4xx/5xx responses, right?
>>
>> As a library maintainer, I'd like to rely on the behavior of the Client,
>> so either ALWAYS or NEVER, not depending om some hidden config. Otherwise
>> I'd have to check both cases again every time.
>> And in that case my preference would be to NOT throw exceptions on
>> 4xx/5xx errors.
>>
>> Hope this will make it to a real PSR soon :) Good job!
>>
>
> Agreed 100% about having an ALWAYS/NEVER decision on exceptions.  I differ
> on my preference, but I also defer to those maintaining and using http
> clients on a regular basis.  Jason made the argument that the exception is
> on the remote end, but I take the view that the consumer was expecting a
> response and didn't get one. That's exceptional.  The client gets to decide
> how it handles that error whether it's a status code or an exception, so
> that half of the argument doesn't hold.  By the same token, that also means
> that as a consumer, I don't really care what the library does so long as
> it's consistent, so I come back to the start: Just define ALWAYS/NEVER and
> the rest of us will deal with it from there.
>
> --
> 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/8cd91c71-0738-4aee-8391-54cff756051b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CANBrOc0cev28721Q3R%2Bs2x%3D%3DADHvtudQHDr3v09dkhhi%3DW%3DxLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Sara Golemon]

On Friday, August 25, 2017 at 4:10:06 AM UTC-4, Barry vd. Heuvel wrote:
>
> So given the unanimous support for the HTTP Client and the current 
> implementations, the only actual point of discussion is the throwing of 
> Exceptions on 4xx/5xx responses, right?
>
> As a library maintainer, I'd like to rely on the behavior of the Client, 
> so either ALWAYS or NEVER, not depending om some hidden config. Otherwise 
> I'd have to check both cases again every time. 
> And in that case my preference would be to NOT throw exceptions on 4xx/5xx 
> errors.
>
> Hope this will make it to a real PSR soon :) Good job!
>

Agreed 100% about having an ALWAYS/NEVER decision on exceptions.  I differ 
on my preference, but I also defer to those maintaining and using http 
clients on a regular basis.  Jason made the argument that the exception is 
on the remote end, but I take the view that the consumer was expecting a 
response and didn't get one. That's exceptional.  The client gets to decide 
how it handles that error whether it's a status code or an exception, so 
that half of the argument doesn't hold.  By the same token, that also means 
that as a consumer, I don't really care what the library does so long as 
it's consistent, so I come back to the start: Just define ALWAYS/NEVER and 
the rest of us will deal with it from there.

-- 
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/8cd91c71-0738-4aee-8391-54cff756051b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Jan Schneider]

est  
did not fail, it's the Request object that was invalid.

   
   * Thrown when the request cannot be completed  
because of network issues. * There is no response object as  
this exception is thrown when no response has been received. *  
Example: the target host name can not be resolved or the  
connection failed.interface NetworkException extends Exception

   
  NetworkErrorException? OK maybe this one is too  
much (NetworkError would be better but…)

   
  And as said above HttpException should probably  
be removed entirely?

   
  Matthieu

Le mardi 11 juillet 2017 18:33:15 UTC+2, Larry Garfield a écrit :
I'm inclined to agree here.  Error handling that may change  
based on some config not available to me in local scope, like  
PDO does, is a design flaw, as I then have to account for both  
possible error flows.


I could be argued in favor of exceptions always or exceptions  
never (I'm leaning exceptions on all 4xx/xx right now, but  
could be convinced otherwise), but "exceptions sometimes"  
doesn't seem like a good choice.


That said, that's a detail that doesn't block officially  
forming the WG; I'm +1 on approving this as a WG to hash out  
exactly those sorts of details.


--Larry Garfield

 On 07/11/2017 11:12 AM, Josh Di Fabio wrote:

Right, I see; I saw the /HttpException/ class but I missed  
that it /MUST NOT be thrown when using the client's default  
configuration./  
   Having said that, I think the fact that  
the behaviour of /sendRequest()/ varies based on some  
configuration which isn't available via the interface is  
actually worse than always throwing. Given that most people  
will be injecting their /HttpClient/ instance into other  
objects and probably passing one instance around to multiple  
classes, the code which is calling /sendRequest()/ won't  
generally have visibility over how the client is configured,  
so we'll have to be super defensive when calling the client  
to be sure we handle 4xx and 5xx responses correctly:  
    

try {
    $rep = $client->sendRequest($req);
} catch (HttpException $e) {
    $rep = $e->getResponse();
}
 
It should either always throw or never  
throw. The behaviour of redirects should also be consistent  
or configurable via the interface or else autowiring will be  
useless for instances of /HttpClient/.

 
   
On Tue, Jul 11, 2017 at 4:51 PM  
 wrote:



I think I've been unclear or you misread something. 
A HTTP client MUST NOT throw exceptions for any response. 
  
 So I very much agree with you. 
 


On 11 Jul 2017, at 17:45, Josh Di Fabio  
 wrote:

 


This looks pretty good, but I don't like exceptions for 4xx  
and 5xx responses, which smells of exceptions for flow  
control. Within the context of HTTP there is nothing  
exceptional about 4xx and 5xx responses. Rather, whether a  
certain response status is considered exceptional depends  
on the context of the caller. For example, in many contexts  
a 3xx response would be unexpected but a 404 response would  
not. Instead of throwing, the client should simply return  
the response.


   On  
Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai  
 wrote:


Very good suggestions.  
   Also, it's very pleasant to see a  
PSR pushed this way and backed from the start by a working  
lib and all the interestend players. Really good job!




Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry  
Garfield ha scritto:




On 07/07/2017 12:20 PM, Tobias Nyholm wrote:

Excellent questions. Thank you.   
  
   The buy-in would be  
the same for every PSR, wouldn't it? Libraries do not  
want to depend on an implementation or provide an  
implementation themselves. They want the user to decide  
if a highly flexible client (Guzzle) or a  
lightweight/fast client (php-http/curl-client). (Source:  
https://github.com/joelwurtz/http-client-benchmark).  
Also, as you probably noticed, there are representatives  
from all PSR7 compliant HTTP clients in the workgroup.


That last point was what I was getting at, thank you.  By  
buy-in, I mean "do we have an indication that the major  
HTTP clients are going to adopt it?"  It sounds like the  
answer is a loud "yes", which is great to see.


The simples

Re: PSR for HTTP clients

[Niels Braczek]

Am 28.08.2017 um 22:43 schrieb Larry Garfield:

> Proposed guideline for the client:
> 
> - If it's possible to return an accurate HTTP response object, do so,
> whatever it is.  (Even if it's a 500 or 418, it's still a valid response
> object.)
> 
> - If it's not possible to return an accurate HTTP response object, throw
> an appropriate exception.  Because there's no legit return value to
> return, an exception is the appropriate alternative.
> 
> Does that seem reasonable?

Sounds very reasonable to me (although my voice don't count much).

Regards,
Niels

-- 
| New Stars on the Horizon:  GreenCape  ·  nibralab  ·  laJoom |
| http://www.bsds.de   ·   BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
 --

-- 
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/6432a196-2737-2540-9e8d-a63f30ce94fd%40bsds.de.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Larry Garfield]

>>
>>
>> On 11 Jul 2017, at 17:45, Josh Di Fabio
>>  wrote:
>>
>>> This looks pretty good, but I don't like
>>> exceptions for 4xx and 5xx responses, which
>>> smells of exceptions for flow control.
>>> Within the context of HTTP there is nothing
>>> exceptional about 4xx and 5xx responses.
>>> Rather, whether a certain response status is
>>> considered exceptional depends on the
>>> context of the caller. For example, in many
>>> contexts a 3xx response would be unexpected
>>> but a 404 response would not. Instead of
>>> throwing, the client should simply return
>>> the response.
>>>
>>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro
>>> Lai  wrote:
>>>
>>> Very good suggestions.
>>> Also, it's very pleasant to see a PSR
>>> pushed this way and backed from the
>>> start by a working lib and all the
>>> interestend players. Really good job!
>>>
>>>
>>> Il giorno lunedì 10 luglio 2017 00:38:32
>>> UTC+2, Larry Garfield ha scritto:
>>>
>>> On 07/07/2017 12:20 PM, Tobias
>>> Nyholm wrote:
>>>> Excellent questions. Thank you. 
>>>>
>>>> The buy-in would be the same for
>>>> every PSR, wouldn't it? Libraries
>>>> do not want to depend on an
>>>> implementation or provide an
>>>> implementation themselves. They
>>>> want the user to decide if a highly
>>>> flexible client (Guzzle) or a
>>>> lightweight/fast client
>>>>         (php-http/curl-client). (Source:
>>>> 
>>>> https://github.com/joelwurtz/http-client-benchmark
>>>> 
>>>> <https://github.com/joelwurtz/http-client-benchmark>).
>>>> Also, as you probably noticed,
>>>> there are representatives from all
>>>> PSR7 compliant HTTP clients in the
>>>> workgroup.
>>>
>>> That last point was what I was
>>> getting at, thank you.  By buy-in, I
>>> mean "do we have an indication that
>>> the major HTTP clients are going to
>>> adopt it?"  It sounds like the
>>> answer is a loud "yes", which is
>>> great to see.
>>>
>>>> The simplest answer of async or not
>>>> is: There is not PSR for Promises
>>>> yet. I do not think the PSR for
>>>> HTTP clients should define what the
>>>> industry standard for a Promise
>>>> should be. I do also not think we
>>>> should wait with a PSR for HTTP
>>>> clients until (if ever) a PSR for
>>>> promises has been released. 
>>>>
>>>> We, php-http team, have followed
>>>> discussions
>>>> in https://github.com/async-interop
>>>> <https://github.com/async-interop>
>>>>

Re: PSR for HTTP clients

[Jason Judge]

l, it's the 
>>>> Request object that was invalid.
>>>>
>>>>  * Thrown when the request cannot be completed because of network issues. 
>>>> * There is no response object as this exception is thrown when no response 
>>>> has been received. * Example: the target host name can not be resolved or 
>>>> the connection failed.interface NetworkException extends Exception
>>>>
>>>>
>>>> NetworkErrorException? OK maybe this one is too much (NetworkError 
>>>> would be better but…)
>>>>
>>>> And as said above HttpException should probably be removed entirely?
>>>>
>>>> Matthieu
>>>>
>>>> Le mardi 11 juillet 2017 18:33:15 UTC+2, Larry Garfield a écrit :
>>>>>
>>>>> I'm inclined to agree here.  Error handling that may change based on 
>>>>> some config not available to me in local scope, like PDO does, is a 
>>>>> design 
>>>>> flaw, as I then have to account for both possible error flows.
>>>>>
>>>>> I could be argued in favor of exceptions always or exceptions never 
>>>>> (I'm leaning exceptions on all 4xx/xx right now, but could be convinced 
>>>>> otherwise), but "exceptions sometimes" doesn't seem like a good choice.
>>>>>
>>>>> That said, that's a detail that doesn't block officially forming the 
>>>>> WG; I'm +1 on approving this as a WG to hash out exactly those sorts of 
>>>>> details.
>>>>>
>>>>> --Larry Garfield
>>>>>
>>>>> On 07/11/2017 11:12 AM, Josh Di Fabio wrote:
>>>>>
>>>>> Right, I see; I saw the *HttpException* class but I missed that it *MUST 
>>>>> NOT be thrown when using the client's default configuration.* 
>>>>>
>>>>> Having said that, I think the fact that the behaviour of 
>>>>> *sendRequest()* varies based on some configuration which isn't 
>>>>> available via the interface is actually worse than always throwing. Given 
>>>>> that most people will be injecting their *HttpClient* instance into 
>>>>> other objects and probably passing one instance around to multiple 
>>>>> classes, 
>>>>> the code which is calling *sendRequest()* won't generally have 
>>>>> visibility over how the client is configured, so we'll have to be super 
>>>>> defensive when calling the client to be sure we handle 4xx and 5xx 
>>>>> responses correctly: 
>>>>>
>>>>> try {
>>>>> $rep = $client->sendRequest($req);
>>>>> } catch (HttpException $e) {
>>>>> $rep = $e->getResponse();
>>>>> }
>>>>>
>>>>> It should either always throw or never throw. The behaviour of 
>>>>> redirects should also be consistent or configurable via the interface or 
>>>>> else autowiring will be useless for instances of *HttpClient*.
>>>>>
>>>>> On Tue, Jul 11, 2017 at 4:51 PM  wrote:
>>>>>
>>>>>> I think I've been unclear or you misread something. 
>>>>>> A HTTP client MUST NOT throw exceptions for any response. 
>>>>>>
>>>>>> So I very much agree with you. 
>>>>>>
>>>>>>
>>>>>> On 11 Jul 2017, at 17:45, Josh Di Fabio  wrote:
>>>>>>
>>>>>> This looks pretty good, but I don't like exceptions for 4xx and 5xx 
>>>>>> responses, which smells of exceptions for flow control. Within the 
>>>>>> context 
>>>>>> of HTTP there is nothing exceptional about 4xx and 5xx responses. 
>>>>>> Rather, 
>>>>>> whether a certain response status is considered exceptional depends on 
>>>>>> the 
>>>>>> context of the caller. For example, in many contexts a 3xx response 
>>>>>> would 
>>>>>> be unexpected but a 404 response would not. Instead of throwing, the 
>>>>>> client 
>>>>>> should simply return the response.
>>>>>>
>>>>>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai <
>>>>>> alessand...@gmail.com> wrote:
>>>>>>
>>>>>>> Very good suggestions. 
>>>>>>> 

Re: PSR for HTTP clients

[Barry vd. Heuvel]

 
>>>> otherwise), but "exceptions sometimes" doesn't seem like a good choice.
>>>>
>>>> That said, that's a detail that doesn't block officially forming the 
>>>> WG; I'm +1 on approving this as a WG to hash out exactly those sorts of 
>>>> details.
>>>>
>>>> --Larry Garfield
>>>>
>>>> On 07/11/2017 11:12 AM, Josh Di Fabio wrote:
>>>>
>>>> Right, I see; I saw the *HttpException* class but I missed that it *MUST 
>>>> NOT be thrown when using the client's default configuration.* 
>>>>
>>>> Having said that, I think the fact that the behaviour of 
>>>> *sendRequest()* varies based on some configuration which isn't 
>>>> available via the interface is actually worse than always throwing. Given 
>>>> that most people will be injecting their *HttpClient* instance into 
>>>> other objects and probably passing one instance around to multiple 
>>>> classes, 
>>>> the code which is calling *sendRequest()* won't generally have 
>>>> visibility over how the client is configured, so we'll have to be super 
>>>> defensive when calling the client to be sure we handle 4xx and 5xx 
>>>> responses correctly: 
>>>>
>>>> try {
>>>> $rep = $client->sendRequest($req);
>>>> } catch (HttpException $e) {
>>>> $rep = $e->getResponse();
>>>> }
>>>>
>>>> It should either always throw or never throw. The behaviour of 
>>>> redirects should also be consistent or configurable via the interface or 
>>>> else autowiring will be useless for instances of *HttpClient*.
>>>>
>>>> On Tue, Jul 11, 2017 at 4:51 PM  wrote:
>>>>
>>>>> I think I've been unclear or you misread something. 
>>>>> A HTTP client MUST NOT throw exceptions for any response. 
>>>>>
>>>>> So I very much agree with you. 
>>>>>
>>>>>
>>>>> On 11 Jul 2017, at 17:45, Josh Di Fabio  wrote:
>>>>>
>>>>> This looks pretty good, but I don't like exceptions for 4xx and 5xx 
>>>>> responses, which smells of exceptions for flow control. Within the 
>>>>> context 
>>>>> of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather, 
>>>>> whether a certain response status is considered exceptional depends on 
>>>>> the 
>>>>> context of the caller. For example, in many contexts a 3xx response would 
>>>>> be unexpected but a 404 response would not. Instead of throwing, the 
>>>>> client 
>>>>> should simply return the response.
>>>>>
>>>>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai  
>>>>> wrote:
>>>>>
>>>>>> Very good suggestions. 
>>>>>> Also, it's very pleasant to see a PSR pushed this way and backed from 
>>>>>> the start by a working lib and all the interestend players. Really good 
>>>>>> job!
>>>>>>
>>>>>>
>>>>>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha 
>>>>>> scritto:
>>>>>>
>>>>>>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>>>>>>
>>>>>>> Excellent questions. Thank you.  
>>>>>>>
>>>>>>> The buy-in would be the same for every PSR, wouldn't it? Libraries 
>>>>>>> do not want to depend on an implementation or provide an implementation 
>>>>>>> themselves. They want the user to decide if a highly flexible client 
>>>>>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
>>>>>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you 
>>>>>>> probably noticed, there are representatives from all PSR7 compliant 
>>>>>>> HTTP 
>>>>>>> clients in the workgroup. 
>>>>>>>
>>>>>>>
>>>>>>> That last point was what I was getting at, thank you.  By buy-in, I 
>>>>>>> mean "do we have an indication that the major HTTP clients are going to 
>>>>>>> adopt it?"  It sounds like the answer is a loud "yes", which is great 
>>>>>>> to 
>>>>

Re: PSR for HTTP clients

[Tobias Nyholm]

t; Very good suggestions. 
>>>> Also, it's very pleasant to see a PSR pushed this way and backed from 
>>>> the start by a working lib and all the interestend players. Really good 
>>>> job!
>>>>
>>>>
>>>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha 
>>>> scritto:
>>>>
>>>>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>>>>
>>>>> Excellent questions. Thank you.  
>>>>>
>>>>> The buy-in would be the same for every PSR, wouldn't it? Libraries do 
>>>>> not want to depend on an implementation or provide an implementation 
>>>>> themselves. They want the user to decide if a highly flexible client 
>>>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
>>>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you 
>>>>> probably noticed, there are representatives from all PSR7 compliant HTTP 
>>>>> clients in the workgroup. 
>>>>>
>>>>>
>>>>> That last point was what I was getting at, thank you.  By buy-in, I 
>>>>> mean "do we have an indication that the major HTTP clients are going to 
>>>>> adopt it?"  It sounds like the answer is a loud "yes", which is great to 
>>>>> see.
>>>>>
>>>>> The simplest answer of async or not is: There is not PSR for Promises 
>>>>> yet. I do not think the PSR for HTTP clients should define what the 
>>>>> industry standard for a Promise should be. I do also not think we should 
>>>>> wait with a PSR for HTTP clients until (if ever) a PSR for promises has 
>>>>> been released. 
>>>>>
>>>>> We, php-http team, have followed discussions in 
>>>>> https://github.com/async-interop that sadly has been put on hold. 
>>>>>
>>>>>
>>>>> A fair reason, thanks.  It may be worth mentioning in the metadoc, 
>>>>> including what a future Async version MIGHT look like if/when a Promises 
>>>>> PS 
>>>>> happens.  (You don't need to implement it, just show that it could still 
>>>>> be 
>>>>> implemented.)
>>>>>
>>>>> --Larry Garfield
>>>>>
>>>>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote: 
>>>>>>
>>>>>> The key for me is if the various HTTP clients have buy-in to 
>>>>>> implement the spec once completed.  Is that the case?
>>>>>>
>>>>>> I would also ask why this is just for sync HTTP clients, not async.  
>>>>>> There's plenty of use cases for the latter.  That may be scope creep, 
>>>>>> but I 
>>>>>> feel it's worth asking.
>>>>>>
>>>>>> --Larry Garfield
>>>>>>
>>>>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>>>>
>>>>>> Hi, 
>>>>>>
>>>>>> +1 for first creating working stuff and later doing effort to make it 
>>>>>> a good standard. Way better approach than the other way round :)
>>>>>>
>>>>>> Great work.
>>>>>>
>>>>>> Cheers and great weekends!
>>>>>> --
>>>>>> Tuomas
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  
>>>>>> wrote:
>>>>>>
>>>>>>> Hey, 
>>>>>>>
>>>>>>> This looks interesting, would have to study this in detail but I do 
>>>>>>> like the simplicity from a quick read through.
>>>>>>>
>>>>>>> Cees-Jan 
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm  
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hey.  
>>>>>>>>
>>>>>>>> Im a co-creator of HTTPlug and a maintainer of a number of API 
>>>>>>>> clients. I would really like to see a PSR for synchronous HTTP 
>>>>>>>> clients. The 
>>>>>>>> HTTPlug has created a "meta-standard" which has been stable for 18 
>>>>>>>> month

Re: PSR for HTTP clients

[Matthieu Napoli]

de if a highly flexible client 
>>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
>>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you 
>>>> probably noticed, there are representatives from all PSR7 compliant HTTP 
>>>> clients in the workgroup. 
>>>>
>>>>
>>>> That last point was what I was getting at, thank you.  By buy-in, I 
>>>> mean "do we have an indication that the major HTTP clients are going to 
>>>> adopt it?"  It sounds like the answer is a loud "yes", which is great to 
>>>> see.
>>>>
>>>> The simplest answer of async or not is: There is not PSR for Promises 
>>>> yet. I do not think the PSR for HTTP clients should define what the 
>>>> industry standard for a Promise should be. I do also not think we should 
>>>> wait with a PSR for HTTP clients until (if ever) a PSR for promises has 
>>>> been released. 
>>>>
>>>> We, php-http team, have followed discussions in 
>>>> https://github.com/async-interop that sadly has been put on hold. 
>>>>
>>>>
>>>> A fair reason, thanks.  It may be worth mentioning in the metadoc, 
>>>> including what a future Async version MIGHT look like if/when a Promises 
>>>> PS 
>>>> happens.  (You don't need to implement it, just show that it could still 
>>>> be 
>>>> implemented.)
>>>>
>>>> --Larry Garfield
>>>>
>>>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote: 
>>>>>
>>>>> The key for me is if the various HTTP clients have buy-in to implement 
>>>>> the spec once completed.  Is that the case?
>>>>>
>>>>> I would also ask why this is just for sync HTTP clients, not async.  
>>>>> There's plenty of use cases for the latter.  That may be scope creep, but 
>>>>> I 
>>>>> feel it's worth asking.
>>>>>
>>>>> --Larry Garfield
>>>>>
>>>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>>>
>>>>> Hi, 
>>>>>
>>>>> +1 for first creating working stuff and later doing effort to make it 
>>>>> a good standard. Way better approach than the other way round :)
>>>>>
>>>>> Great work.
>>>>>
>>>>> Cheers and great weekends!
>>>>> --
>>>>> Tuomas
>>>>>
>>>>>
>>>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  
>>>>> wrote:
>>>>>
>>>>>> Hey, 
>>>>>>
>>>>>> This looks interesting, would have to study this in detail but I do 
>>>>>> like the simplicity from a quick read through.
>>>>>>
>>>>>> Cees-Jan 
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm  
>>>>>> wrote:
>>>>>>
>>>>>>> Hey.  
>>>>>>>
>>>>>>> Im a co-creator of HTTPlug and a maintainer of a number of API 
>>>>>>> clients. I would really like to see a PSR for synchronous HTTP clients. 
>>>>>>> The 
>>>>>>> HTTPlug has created a "meta-standard" which has been stable for 18 
>>>>>>> months 
>>>>>>> now. We believe it is a really good interface and would like it (or 
>>>>>>> something similar) to be an official PSR. 
>>>>>>>
>>>>>>> I would ask the Fig for an entrance vote.
>>>>>>>
>>>>>>> *Here is a first idea: *
>>>>>>> PSR: 
>>>>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>>>>>>> Meta: 
>>>>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>>>>>>
>>>>>>> *Workgroup*:
>>>>>>> These people has been contacted and said they are interested in 
>>>>>>> participating in a workgroup. 
>>>>>>>
>>>>>>>- Tobias Nyholm
>>>>>>>- Sara Golemon (cc)
>>>>>>>- Matthew O'Phinney (cc) (Maybe)
>>>>>&g

Re: PSR for HTTP clients

[Larry Garfield]

I'm inclined to agree here.  Error handling that may change based on
some config not available to me in local scope, like PDO does, is a
design flaw, as I then have to account for both possible error flows.

I could be argued in favor of exceptions always or exceptions never (I'm
leaning exceptions on all 4xx/xx right now, but could be convinced
otherwise), but "exceptions sometimes" doesn't seem like a good choice.

That said, that's a detail that doesn't block officially forming the WG;
I'm +1 on approving this as a WG to hash out exactly those sorts of details.

--Larry Garfield

On 07/11/2017 11:12 AM, Josh Di Fabio wrote:
> Right, I see; I saw the /HttpException/ class but I missed that it
> /MUST NOT be thrown when using the client's default configuration./
>
> Having said that, I think the fact that the behaviour
> of /sendRequest()/ varies based on some configuration which isn't
> available via the interface is actually worse than always throwing.
> Given that most people will be injecting their /HttpClient/ instance
> into other objects and probably passing one instance around to
> multiple classes, the code which is calling /sendRequest()/ won't
> generally have visibility over how the client is configured, so we'll
> have to be super defensive when calling the client to be sure we
> handle 4xx and 5xx responses correctly:
>
> try {
> $rep = $client->sendRequest($req);
> } catch (HttpException $e) {
> $rep = $e->getResponse();
> }
>
> It should either always throw or never throw. The behaviour of
> redirects should also be consistent or configurable via the interface
> or else autowiring will be useless for instances of /HttpClient/.
>
> On Tue, Jul 11, 2017 at 4:51 PM  <mailto:tobias.nyh...@gmail.com>> wrote:
>
> I think I've been unclear or you misread something. 
> A HTTP client MUST NOT throw exceptions for any response. 
>
> So I very much agree with you. 
>
>
> On 11 Jul 2017, at 17:45, Josh Di Fabio  <mailto:joshdifa...@gmail.com>> wrote:
>
>> This looks pretty good, but I don't like exceptions for 4xx and
>> 5xx responses, which smells of exceptions for flow control.
>> Within the context of HTTP there is nothing exceptional about 4xx
>> and 5xx responses. Rather, whether a certain response status is
>> considered exceptional depends on the context of the caller. For
>> example, in many contexts a 3xx response would be unexpected but
>> a 404 response would not. Instead of throwing, the client should
>> simply return the response.
>>
>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai
>> mailto:alessandro.la...@gmail.com>>
>> wrote:
>>
>> Very good suggestions.
>> Also, it's very pleasant to see a PSR pushed this way and
>> backed from the start by a working lib and all the
>> interestend players. Really good job!
>>
>>
>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry
>> Garfield ha scritto:
>>
>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>> Excellent questions. Thank you. 
>>>
>>> The buy-in would be the same for every PSR, wouldn't it?
>>> Libraries do not want to depend on an implementation or
>>> provide an implementation themselves. They want the user
>>> to decide if a highly flexible client (Guzzle) or a
>>> lightweight/fast client (php-http/curl-client). (Source:
>>> https://github.com/joelwurtz/http-client-benchmark).
>>> Also, as you probably noticed, there are representatives
>>> from all PSR7 compliant HTTP clients in the workgroup.
>>
>> That last point was what I was getting at, thank you.  By
>> buy-in, I mean "do we have an indication that the major
>> HTTP clients are going to adopt it?"  It sounds like the
>> answer is a loud "yes", which is great to see.
>>
>>> The simplest answer of async or not is: There is not PSR
>>> for Promises yet. I do not think the PSR for HTTP
>>> clients should define what the industry standard for a
>>> Promise should be. I do also not think we should wait
>>> with a PSR for HTTP clients until (if ever) a PSR for
>>> promises has been released. 
>>>
>>> We, php-http team, have followed discussions
>>> 

Re: PSR for HTTP clients

[Josh Di Fabio]

Right, I see; I saw the *HttpException* class but I missed that it *MUST
NOT be thrown when using the client's default configuration.*

Having said that, I think the fact that the behaviour of *sendRequest()* varies
based on some configuration which isn't available via the interface is
actually worse than always throwing. Given that most people will be
injecting their *HttpClient* instance into other objects and probably
passing one instance around to multiple classes, the code which is calling
*sendRequest()* won't generally have visibility over how the client is
configured, so we'll have to be super defensive when calling the client to
be sure we handle 4xx and 5xx responses correctly:

try {
$rep = $client->sendRequest($req);
} catch (HttpException $e) {
$rep = $e->getResponse();
}

It should either always throw or never throw. The behaviour of redirects
should also be consistent or configurable via the interface or else
autowiring will be useless for instances of *HttpClient*.

On Tue, Jul 11, 2017 at 4:51 PM  wrote:

> I think I've been unclear or you misread something.
> A HTTP client MUST NOT throw exceptions for any response.
>
> So I very much agree with you.
>
>
> On 11 Jul 2017, at 17:45, Josh Di Fabio  wrote:
>
> This looks pretty good, but I don't like exceptions for 4xx and 5xx
> responses, which smells of exceptions for flow control. Within the context
> of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather,
> whether a certain response status is considered exceptional depends on the
> context of the caller. For example, in many contexts a 3xx response would
> be unexpected but a 404 response would not. Instead of throwing, the client
> should simply return the response.
>
> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai <
> alessandro.la...@gmail.com> wrote:
>
>> Very good suggestions.
>> Also, it's very pleasant to see a PSR pushed this way and backed from the
>> start by a working lib and all the interestend players. Really good job!
>>
>>
>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto:
>>
>>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>>
>>> Excellent questions. Thank you.
>>>
>>> The buy-in would be the same for every PSR, wouldn't it? Libraries do
>>> not want to depend on an implementation or provide an implementation
>>> themselves. They want the user to decide if a highly flexible client
>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source:
>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you
>>> probably noticed, there are representatives from all PSR7 compliant HTTP
>>> clients in the workgroup.
>>>
>>>
>>> That last point was what I was getting at, thank you.  By buy-in, I mean
>>> "do we have an indication that the major HTTP clients are going to adopt
>>> it?"  It sounds like the answer is a loud "yes", which is great to see.
>>>
>>> The simplest answer of async or not is: There is not PSR for Promises
>>> yet. I do not think the PSR for HTTP clients should define what the
>>> industry standard for a Promise should be. I do also not think we should
>>> wait with a PSR for HTTP clients until (if ever) a PSR for promises has
>>> been released.
>>>
>>> We, php-http team, have followed discussions in
>>> https://github.com/async-interop that sadly has been put on hold.
>>>
>>>
>>> A fair reason, thanks.  It may be worth mentioning in the metadoc,
>>> including what a future Async version MIGHT look like if/when a Promises PS
>>> happens.  (You don't need to implement it, just show that it could still be
>>> implemented.)
>>>
>>> --Larry Garfield
>>>
>>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>>>>
>>>> The key for me is if the various HTTP clients have buy-in to implement
>>>> the spec once completed.  Is that the case?
>>>>
>>>> I would also ask why this is just for sync HTTP clients, not async.
>>>> There's plenty of use cases for the latter.  That may be scope creep, but I
>>>> feel it's worth asking.
>>>>
>>>> --Larry Garfield
>>>>
>>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>>
>>>> Hi,
>>>>
>>>> +1 for first creating working stuff and later doing effort to make it a
>>>> good standard. Way better approach than the other way round :)
>>>>
>>>&g

Re: PSR for HTTP clients

[tobias . nyholm]

I think I've been unclear or you misread something. 
A HTTP client MUST NOT throw exceptions for any response. 

So I very much agree with you. 


> On 11 Jul 2017, at 17:45, Josh Di Fabio  wrote:
> 
> This looks pretty good, but I don't like exceptions for 4xx and 5xx 
> responses, which smells of exceptions for flow control. Within the context of 
> HTTP there is nothing exceptional about 4xx and 5xx responses. Rather, 
> whether a certain response status is considered exceptional depends on the 
> context of the caller. For example, in many contexts a 3xx response would be 
> unexpected but a 404 response would not. Instead of throwing, the client 
> should simply return the response.
> 
>> On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai  
>> wrote:
>> Very good suggestions.
>> Also, it's very pleasant to see a PSR pushed this way and backed from the 
>> start by a working lib and all the interestend players. Really good job!
>> 
>> 
>> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto:
>>>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>>> Excellent questions. Thank you. 
>>>> 
>>>> The buy-in would be the same for every PSR, wouldn't it? Libraries do not 
>>>> want to depend on an implementation or provide an implementation 
>>>> themselves. They want the user to decide if a highly flexible client 
>>>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
>>>> https://github.com/joelwurtz/http-client-benchmark). Also, as you probably 
>>>> noticed, there are representatives from all PSR7 compliant HTTP clients in 
>>>> the workgroup. 
>>> 
>>> That last point was what I was getting at, thank you.  By buy-in, I mean 
>>> "do we have an indication that the major HTTP clients are going to adopt 
>>> it?"  It sounds like the answer is a loud "yes", which is great to see.
>>> 
>>>> The simplest answer of async or not is: There is not PSR for Promises yet. 
>>>> I do not think the PSR for HTTP clients should define what the industry 
>>>> standard for a Promise should be. I do also not think we should wait with 
>>>> a PSR for HTTP clients until (if ever) a PSR for promises has been 
>>>> released. 
>>>> 
>>>> We, php-http team, have followed discussions in 
>>>> https://github.com/async-interop that sadly has been put on hold. 
>>> 
>>> A fair reason, thanks.  It may be worth mentioning in the metadoc, 
>>> including what a future Async version MIGHT look like if/when a Promises PS 
>>> happens.  (You don't need to implement it, just show that it could still be 
>>> implemented.)
>>> 
>>> --Larry Garfield
>>> 
>> 
>>>>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>>>>> The key for me is if the various HTTP clients have buy-in to implement 
>>>>> the spec once completed.  Is that the case?
>>>>> 
>>>>> I would also ask why this is just for sync HTTP clients, not async.  
>>>>> There's plenty of use cases for the latter.  That may be scope creep, but 
>>>>> I feel it's worth asking.
>>>>> 
>>>>> --Larry Garfield
>>>>> 
>>>>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> +1 for first creating working stuff and later doing effort to make it a 
>>>>>> good standard. Way better approach than the other way round :)
>>>>>> 
>>>>>> Great work.
>>>>>> 
>>>>>> Cheers and great weekends!
>>>>>> --
>>>>>> Tuomas
>>>>>> 
>>>>>> 
>>>>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  
>>>>>> wrote:
>>>>>>> Hey,
>>>>>>> 
>>>>>>> This looks interesting, would have to study this in detail but I do 
>>>>>>> like the simplicity from a quick read through.
>>>>>>> 
>>>>>>> Cees-Jan
>>>>>>> 
>>>>>>> 
>>>>>>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm 
>>>>>>>>wrote:
>>>>>>>> Hey. 
>>>>>>>> 
>>>>>>>> Im a co-creator of HTTPlug and a mainta

Re: PSR for HTTP clients

[Josh Di Fabio]

This looks pretty good, but I don't like exceptions for 4xx and 5xx
responses, which smells of exceptions for flow control. Within the context
of HTTP there is nothing exceptional about 4xx and 5xx responses. Rather,
whether a certain response status is considered exceptional depends on the
context of the caller. For example, in many contexts a 3xx response would
be unexpected but a 404 response would not. Instead of throwing, the client
should simply return the response.

On Tue, Jul 11, 2017 at 12:48 PM Alessandro Lai 
wrote:

> Very good suggestions.
> Also, it's very pleasant to see a PSR pushed this way and backed from the
> start by a working lib and all the interestend players. Really good job!
>
>
> Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto:
>
>> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>>
>> Excellent questions. Thank you.
>>
>> The buy-in would be the same for every PSR, wouldn't it? Libraries do not
>> want to depend on an implementation or provide an implementation
>> themselves. They want the user to decide if a highly flexible client
>> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source:
>> https://github.com/joelwurtz/http-client-benchmark). Also, as you
>> probably noticed, there are representatives from all PSR7 compliant HTTP
>> clients in the workgroup.
>>
>>
>> That last point was what I was getting at, thank you.  By buy-in, I mean
>> "do we have an indication that the major HTTP clients are going to adopt
>> it?"  It sounds like the answer is a loud "yes", which is great to see.
>>
>> The simplest answer of async or not is: There is not PSR for Promises
>> yet. I do not think the PSR for HTTP clients should define what the
>> industry standard for a Promise should be. I do also not think we should
>> wait with a PSR for HTTP clients until (if ever) a PSR for promises has
>> been released.
>>
>> We, php-http team, have followed discussions in
>> https://github.com/async-interop that sadly has been put on hold.
>>
>>
>> A fair reason, thanks.  It may be worth mentioning in the metadoc,
>> including what a future Async version MIGHT look like if/when a Promises PS
>> happens.  (You don't need to implement it, just show that it could still be
>> implemented.)
>>
>> --Larry Garfield
>>
>> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>>>
>>> The key for me is if the various HTTP clients have buy-in to implement
>>> the spec once completed.  Is that the case?
>>>
>>> I would also ask why this is just for sync HTTP clients, not async.
>>> There's plenty of use cases for the latter.  That may be scope creep, but I
>>> feel it's worth asking.
>>>
>>> --Larry Garfield
>>>
>>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>>
>>> Hi,
>>>
>>> +1 for first creating working stuff and later doing effort to make it a
>>> good standard. Way better approach than the other way round :)
>>>
>>> Great work.
>>>
>>> Cheers and great weekends!
>>> --
>>> Tuomas
>>>
>>>
>>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet 
>>> wrote:
>>>
>>>> Hey,
>>>>
>>>> This looks interesting, would have to study this in detail but I do
>>>> like the simplicity from a quick read through.
>>>>
>>>> Cees-Jan
>>>>
>>>>
>>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm 
>>>> wrote:
>>>>
>>>>> Hey.
>>>>>
>>>>> Im a co-creator of HTTPlug and a maintainer of a number of API
>>>>> clients. I would really like to see a PSR for synchronous HTTP clients. 
>>>>> The
>>>>> HTTPlug has created a "meta-standard" which has been stable for 18 months
>>>>> now. We believe it is a really good interface and would like it (or
>>>>> something similar) to be an official PSR.
>>>>>
>>>>> I would ask the Fig for an entrance vote.
>>>>>
>>>>> *Here is a first idea: *
>>>>> PSR:
>>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>>>>> Meta:
>>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>>>>
>>>>> *Workgroup*:
>>>>> These peopl

Re: PSR for HTTP clients

[Alessandro Lai]

Very good suggestions.
Also, it's very pleasant to see a PSR pushed this way and backed from the 
start by a working lib and all the interestend players. Really good job!

Il giorno lunedì 10 luglio 2017 00:38:32 UTC+2, Larry Garfield ha scritto:
>
> On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
>
> Excellent questions. Thank you.  
>
> The buy-in would be the same for every PSR, wouldn't it? Libraries do not 
> want to depend on an implementation or provide an implementation 
> themselves. They want the user to decide if a highly flexible client 
> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
> https://github.com/joelwurtz/http-client-benchmark). Also, as you 
> probably noticed, there are representatives from all PSR7 compliant HTTP 
> clients in the workgroup. 
>
>
> That last point was what I was getting at, thank you.  By buy-in, I mean 
> "do we have an indication that the major HTTP clients are going to adopt 
> it?"  It sounds like the answer is a loud "yes", which is great to see.
>
> The simplest answer of async or not is: There is not PSR for Promises yet. 
> I do not think the PSR for HTTP clients should define what the industry 
> standard for a Promise should be. I do also not think we should wait with a 
> PSR for HTTP clients until (if ever) a PSR for promises has been released. 
>
> We, php-http team, have followed discussions in 
> https://github.com/async-interop that sadly has been put on hold. 
>
>
> A fair reason, thanks.  It may be worth mentioning in the metadoc, 
> including what a future Async version MIGHT look like if/when a Promises PS 
> happens.  (You don't need to implement it, just show that it could still be 
> implemented.)
>
> --Larry Garfield
>
> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote: 
>>
>> The key for me is if the various HTTP clients have buy-in to implement 
>> the spec once completed.  Is that the case?
>>
>> I would also ask why this is just for sync HTTP clients, not async.  
>> There's plenty of use cases for the latter.  That may be scope creep, but I 
>> feel it's worth asking.
>>
>> --Larry Garfield
>>
>> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>>
>> Hi, 
>>
>> +1 for first creating working stuff and later doing effort to make it a 
>> good standard. Way better approach than the other way round :)
>>
>> Great work.
>>
>> Cheers and great weekends!
>> --
>> Tuomas
>>
>>
>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  
>> wrote:
>>
>>> Hey, 
>>>
>>> This looks interesting, would have to study this in detail but I do like 
>>> the simplicity from a quick read through.
>>>
>>> Cees-Jan 
>>>
>>>
>>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm  
>>> wrote:
>>>
>>>> Hey.  
>>>>
>>>> Im a co-creator of HTTPlug and a maintainer of a number of API clients. 
>>>> I would really like to see a PSR for synchronous HTTP clients. The HTTPlug 
>>>> has created a "meta-standard" which has been stable for 18 months now. We 
>>>> believe it is a really good interface and would like it (or something 
>>>> similar) to be an official PSR. 
>>>>
>>>> I would ask the Fig for an entrance vote.
>>>>
>>>> *Here is a first idea: *
>>>> PSR: 
>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>>>> Meta: 
>>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>>>
>>>> *Workgroup*:
>>>> These people has been contacted and said they are interested in 
>>>> participating in a workgroup. 
>>>>
>>>>- Tobias Nyholm
>>>>- Sara Golemon (cc)
>>>>- Matthew O'Phinney (cc) (Maybe)
>>>>- Mark Sagi-Kazar 
>>>>- Jermey Lindstrom
>>>>- David Buchmann
>>>>- Joel Wurtz
>>>>- Simon Asika
>>>>- Christian Lück
>>>>- David De Boer
>>>>
>>>>
>>>> -- 
>>>> 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, se

Re: PSR for HTTP clients

[Larry Garfield]

On 07/07/2017 12:20 PM, Tobias Nyholm wrote:
> Excellent questions. Thank you. 
>
> The buy-in would be the same for every PSR, wouldn't it? Libraries do
> not want to depend on an implementation or provide an implementation
> themselves. They want the user to decide if a highly flexible client
> (Guzzle) or a lightweight/fast client (php-http/curl-client). (Source:
> https://github.com/joelwurtz/http-client-benchmark). Also, as you
> probably noticed, there are representatives from all PSR7 compliant
> HTTP clients in the workgroup.

That last point was what I was getting at, thank you.  By buy-in, I mean
"do we have an indication that the major HTTP clients are going to adopt
it?"  It sounds like the answer is a loud "yes", which is great to see.

> The simplest answer of async or not is: There is not PSR for Promises
> yet. I do not think the PSR for HTTP clients should define what the
> industry standard for a Promise should be. I do also not think we
> should wait with a PSR for HTTP clients until (if ever) a PSR for
> promises has been released. 
>
> We, php-http team, have followed discussions
> in https://github.com/async-interop that sadly has been put on hold.

A fair reason, thanks.  It may be worth mentioning in the metadoc,
including what a future Async version MIGHT look like if/when a Promises
PS happens.  (You don't need to implement it, just show that it could
still be implemented.)

--Larry Garfield

> On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>
> The key for me is if the various HTTP clients have buy-in to
> implement the spec once completed.  Is that the case?
>
> I would also ask why this is just for sync HTTP clients, not
> async.  There's plenty of use cases for the latter.  That may be
> scope creep, but I feel it's worth asking.
>
> --Larry Garfield
>
> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>> Hi,
>>
>> +1 for first creating working stuff and later doing effort to
>> make it a good standard. Way better approach than the other way
>> round :)
>>
>> Great work.
>>
>> Cheers and great weekends!
>> --
>> Tuomas
>>
>>
>> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet
>> > wrote:
>>
>> Hey,
>>
>> This looks interesting, would have to study this in detail
>> but I do like the simplicity from a quick read through.
>>
>> Cees-Jan
>>
>>
>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm
>> > wrote:
>>
>> Hey. 
>>
>> Im a co-creator of HTTPlug and a maintainer of a number
>> of API clients. I would really like to see a PSR for
>> synchronous HTTP clients. The HTTPlug has created a
>> "meta-standard" which has been stable for 18 months now.
>> We believe it is a really good interface and would like
>> it (or something similar) to be an official PSR. 
>>
>> I would ask the Fig for an entrance vote.
>>
>> *Here is a first idea: *
>> PSR: 
>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>> 
>> <https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md>
>> Meta: 
>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>> 
>> <https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md>
>>
>> *Workgroup*:
>> These people has been contacted and said they are
>> interested in participating in a workgroup. 
>>
>>   * Tobias Nyholm
>>   * Sara Golemon (cc)
>>   * Matthew O'Phinney (cc) (Maybe)
>>   * Mark Sagi-Kazar 
>>   * Jermey Lindstrom
>>   * David Buchmann
>>   * Joel Wurtz
>>   * Simon Asika
>>   * Christian Lück
>>   * David De Boer
>>
>>
>> -- 
>> 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 pos

Re: PSR for HTTP clients

[Tobias Nyholm]

Excellent questions. Thank you. 

The buy-in would be the same for every PSR, wouldn't it? Libraries do not 
want to depend on an implementation or provide an implementation 
themselves. They want the user to decide if a highly flexible client 
(Guzzle) or a lightweight/fast client (php-http/curl-client). (Source: 
https://github.com/joelwurtz/http-client-benchmark). Also, as you probably 
noticed, there are representatives from all PSR7 compliant HTTP clients in 
the workgroup. 

The simplest answer of async or not is: There is not PSR for Promises yet. 
I do not think the PSR for HTTP clients should define what the industry 
standard for a Promise should be. I do also not think we should wait with a 
PSR for HTTP clients until (if ever) a PSR for promises has been released. 

We, php-http team, have followed discussions 
in https://github.com/async-interop that sadly has been put on hold. 


On Friday, July 7, 2017 at 6:58:36 PM UTC+2, Larry Garfield wrote:
>
> The key for me is if the various HTTP clients have buy-in to implement the 
> spec once completed.  Is that the case?
>
> I would also ask why this is just for sync HTTP clients, not async.  
> There's plenty of use cases for the latter.  That may be scope creep, but I 
> feel it's worth asking.
>
> --Larry Garfield
>
> On 07/07/2017 03:47 AM, Tuomas Koski wrote:
>
> Hi, 
>
> +1 for first creating working stuff and later doing effort to make it a 
> good standard. Way better approach than the other way round :)
>
> Great work.
>
> Cheers and great weekends!
> --
> Tuomas
>
>
> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  > wrote:
>
>> Hey, 
>>
>> This looks interesting, would have to study this in detail but I do like 
>> the simplicity from a quick read through.
>>
>> Cees-Jan 
>>
>>
>> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm > > wrote:
>>
>>> Hey.  
>>>
>>> Im a co-creator of HTTPlug and a maintainer of a number of API clients. 
>>> I would really like to see a PSR for synchronous HTTP clients. The HTTPlug 
>>> has created a "meta-standard" which has been stable for 18 months now. We 
>>> believe it is a really good interface and would like it (or something 
>>> similar) to be an official PSR. 
>>>
>>> I would ask the Fig for an entrance vote.
>>>
>>> *Here is a first idea: *
>>> PSR: 
>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
>>> Meta: 
>>> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
>>>
>>> *Workgroup*:
>>> These people has been contacted and said they are interested in 
>>> participating in a workgroup. 
>>>
>>>- Tobias Nyholm
>>>- Sara Golemon (cc)
>>>- Matthew O'Phinney (cc) (Maybe)
>>>- Mark Sagi-Kazar 
>>>- Jermey Lindstrom
>>>- David Buchmann
>>>- Joel Wurtz
>>>- Simon Asika
>>>- Christian Lück
>>>- David De Boer
>>>
>>>
>>> -- 
>>> 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/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/php-fig/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> 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/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/php-fig/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>  
>>
>&g

Re: PSR for HTTP clients

[Larry Garfield]

The key for me is if the various HTTP clients have buy-in to implement
the spec once completed.  Is that the case?

I would also ask why this is just for sync HTTP clients, not async. 
There's plenty of use cases for the latter.  That may be scope creep,
but I feel it's worth asking.

--Larry Garfield

On 07/07/2017 03:47 AM, Tuomas Koski wrote:
> Hi,
>
> +1 for first creating working stuff and later doing effort to make it
> a good standard. Way better approach than the other way round :)
>
> Great work.
>
> Cheers and great weekends!
> --
> Tuomas
>
>
> On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet  > wrote:
>
> Hey,
>
> This looks interesting, would have to study this in detail but I
> do like the simplicity from a quick read through.
>
> Cees-Jan
>
>
> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm
> mailto:tobias.nyh...@gmail.com>> wrote:
>
> Hey. 
>
> Im a co-creator of HTTPlug and a maintainer of a number of API
> clients. I would really like to see a PSR for synchronous HTTP
> clients. The HTTPlug has created a "meta-standard" which has
> been stable for 18 months now. We believe it is a really good
> interface and would like it (or something similar) to be an
> official PSR. 
>
> I would ask the Fig for an entrance vote.
>
> *Here is a first idea: *
> PSR: 
> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
> 
> 
> Meta: 
> https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md
> 
> 
>
> *Workgroup*:
> These people has been contacted and said they are interested
> in participating in a workgroup. 
>
>   * Tobias Nyholm
>   * Sara Golemon (cc)
>   * Matthew O'Phinney (cc) (Maybe)
>   * Mark Sagi-Kazar 
>   * Jermey Lindstrom
>   * David Buchmann
>   * Joel Wurtz
>   * Simon Asika
>   * Christian Lück
>   * David De Boer
>
>
> -- 
> 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/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout
> .
>
>
>
> -- 
> 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/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com
> 
> .
>
>
> For more options, visit https://groups.google.com/d/optout
> .
>
>
>
>
> -- 
> Cheers,
> --
> Tuomas
>
> Humap Software Ltd
> http://humapsoftware.com
> Twitter: @humapsoftware
> LinkedIn: https://www.linkedin.com/company/humap-software-ltd
> Facebook: http://facebook.com/humapsoftware/
> Instagram: @humapsoftware
> -- 
> 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/CAAND7_93GNv9R0_e%3DU-e%2B%3DfGWh%3D99hHR5RtkQb2Nde%2BvaSj5vA%40mail.gmail.com
> 

Re: PSR for HTTP clients

[Tuomas Koski]

Hi,

+1 for first creating working stuff and later doing effort to make it a
good standard. Way better approach than the other way round :)

Great work.

Cheers and great weekends!
--
Tuomas


On Thu, Jul 6, 2017 at 11:04 PM, Cees-Jan Kiewiet 
wrote:

> Hey,
>
> This looks interesting, would have to study this in detail but I do like
> the simplicity from a quick read through.
>
> Cees-Jan
>
>
> On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm 
> wrote:
>
>> Hey.
>>
>> Im a co-creator of HTTPlug and a maintainer of a number of API clients. I
>> would really like to see a PSR for synchronous HTTP clients. The HTTPlug
>> has created a "meta-standard" which has been stable for 18 months now. We
>> believe it is a really good interface and would like it (or something
>> similar) to be an official PSR.
>>
>> I would ask the Fig for an entrance vote.
>>
>> *Here is a first idea: *
>> PSR: https://github.com/php-http/fig-standards/blob/master/
>> proposed/http-client/http-client.md
>> Meta: https://github.com/php-http/fig-standards/blob/master/
>> proposed/http-client/http-client-meta.md
>>
>> *Workgroup*:
>> These people has been contacted and said they are interested in
>> participating in a workgroup.
>>
>>- Tobias Nyholm
>>- Sara Golemon (cc)
>>- Matthew O'Phinney (cc) (Maybe)
>>- Mark Sagi-Kazar
>>- Jermey Lindstrom
>>- David Buchmann
>>- Joel Wurtz
>>- Simon Asika
>>- Christian Lück
>>- David De Boer
>>
>>
>> --
>> 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/ms
>> gid/php-fig/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%
> 2BdtLcADMqAwA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
--
Tuomas

Humap Software Ltd
http://humapsoftware.com
Twitter: @humapsoftware
LinkedIn: https://www.linkedin.com/company/humap-software-ltd
Facebook: http://facebook.com/humapsoftware/
Instagram: @humapsoftware

-- 
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/CAAND7_93GNv9R0_e%3DU-e%2B%3DfGWh%3D99hHR5RtkQb2Nde%2BvaSj5vA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR for HTTP clients

[Cees-Jan Kiewiet]

Hey,

This looks interesting, would have to study this in detail but I do like
the simplicity from a quick read through.

Cees-Jan

On Thu, Jul 6, 2017 at 6:08 PM, Tobias Nyholm 
wrote:

> Hey.
>
> Im a co-creator of HTTPlug and a maintainer of a number of API clients. I
> would really like to see a PSR for synchronous HTTP clients. The HTTPlug
> has created a "meta-standard" which has been stable for 18 months now. We
> believe it is a really good interface and would like it (or something
> similar) to be an official PSR.
>
> I would ask the Fig for an entrance vote.
>
> *Here is a first idea: *
> PSR: https://github.com/php-http/fig-standards/blob/
> master/proposed/http-client/http-client.md
> Meta: https://github.com/php-http/fig-standards/blob/
> master/proposed/http-client/http-client-meta.md
>
> *Workgroup*:
> These people has been contacted and said they are interested in
> participating in a workgroup.
>
>- Tobias Nyholm
>- Sara Golemon (cc)
>- Matthew O'Phinney (cc) (Maybe)
>- Mark Sagi-Kazar
>- Jermey Lindstrom
>- David Buchmann
>- Joel Wurtz
>- Simon Asika
>- Christian Lück
>- David De Boer
>
>
> --
> 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/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAPY1sU_e%2BwDVGGm-3VGZzjNfPUpAyA3Ng6tk04%2BdtLcADMqAwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

PSR for HTTP clients

[Tobias Nyholm]

Hey. 

Im a co-creator of HTTPlug and a maintainer of a number of API clients. I 
would really like to see a PSR for synchronous HTTP clients. The HTTPlug 
has created a "meta-standard" which has been stable for 18 months now. We 
believe it is a really good interface and would like it (or something 
similar) to be an official PSR. 

I would ask the Fig for an entrance vote.

*Here is a first idea: *
PSR: 
https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client.md
Meta: 
https://github.com/php-http/fig-standards/blob/master/proposed/http-client/http-client-meta.md

*Workgroup*:
These people has been contacted and said they are interested in 
participating in a workgroup. 

   - Tobias Nyholm
   - Sara Golemon (cc)
   - Matthew O'Phinney (cc) (Maybe)
   - Mark Sagi-Kazar 
   - Jermey Lindstrom
   - David Buchmann
   - Joel Wurtz
   - Simon Asika
   - Christian Lück
   - David De Boer
   

-- 
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/0db70a2c-d528-44df-b7f5-62387eb67872%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.