See https://github.com/php-fig/fig-standards/pull/24
From the introduction:
Many libraries and applications require an HTTP client to talk to
other servers. In general all these libraries either ship their own HTTP
client library, or use low-level PHP functionality such as file_get_contents
,
ext/curl or the ext/socket. Depending on the use-cases there are very
tricky implementation details to be handled such as proxies, SSL,
authentication protocols and many more. Not every small library can
afford to implement all the different details. However there are only a
few http client libraries that are widely used between different
projects, because of NIH or fears of vendor lock-in.
Motivation:
Doctrine has about 4 projects that need an HTTP client. Currently
every projects implements them itself, which is annoying. We could
abstract this into our "Common" library, however that would mean we
would start being a "http client" vendor. Now personally, i don't care
about http clients and would rather let others do this, however i also
don't want to face vendor lock-in by deciding for any of the many http
clients. In a perfect world (with this standard) Doctrine could ship one very simple http client using sockets, and if anyone needs something more awesome, he could just use any other provider of a PSR http client.
--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
To post to this group, send email to php-st...@googlegroups.com.
To unsubscribe from this group, send email to php-standard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/php-standards?hl=en.
--
I realize this is a long shot, but in my dream world the Symfony
HttpFoundation classes for request/response would be made standard.
Their use in the framework & then adoption by Drupal, PPI (?) and
perhaps others make them a great candidate.
For those that don't know it:
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Request.php
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Response.php
The use of public properties for some things make them hard to be turned
into interfaces, but anyone can rely on that component and just use
those classes. I guess Composer adoption isn't broad enough for people
to agree with me that this is ok though.
Cheers
--
Jordi Boggiano
@seldaek - http://nelm.io/jordi
> See https://github.com/php-fig/fig-standards/pull/24
>
> From the introduction:
>
> Many libraries and applications require an HTTP client to talk to other servers. In general all these libraries either ship their own HTTP client library, or use low-level PHP functionality such as file_get_contents, ext/curl or the ext/socket. Depending on the use-cases there are very tricky implementation details to be handled such as proxies, SSL, authentication protocols and many more. Not every small library can afford to implement all the different details. However there are only a few http client libraries that are widely used between different projects, because of NIH or fears of vendor lock-in.
>
> Motivation:
>
> Doctrine has about 4 projects that need an HTTP client. Currently every projects implements them itself, which is annoying. We could abstract this into our "Common" library, however that would mean we would start being a "http client" vendor. Now personally, i don't care about http clients and would rather let others do this, however i also don't want to face vendor lock-in by deciding for any of the many http clients. In a perfect world (with this standard) Doctrine could ship one very simple http client using sockets, and if anyone needs something more awesome, he could just use any other provider of a PSR http client.
>
> Questions:
>
> 1. Do the voting members think this is something to standardize?
I personally feel that this group should focus on interface, not implementation.
There is definitely something amiss in the PHP world, where a lot of project have trouble depending on external components.
But introducing a new one, doesn't really solve that I feel. What we need is more people on board with composer.phar,
and have solid, minimal components that projects like doctrine feel comfortable with to add as a dependency.
I _do_ think there is a lot of value in a common request and response interface though. Not just for HTTP client, but
also to wrap $_SERVER, php://output, header(), etc..
If these 2 interfaces exist, it would also not be terribly hard to define a very simple interface for making requests.
After all, at that point all that's really required is a method that takes a Request object, and returns a Response object.
At that point all doctrine would have to do is to provide a way for users to inject the 'Client' interface.
I feel the end-result of your proposal is a nobel and useful one, but I have serious doubts this should be done through PSR.
Evert
> I personally feel that this group should focus on interface, not implementation.
> There is definitely something amiss in the PHP world, where a lot of project have trouble depending on external components.
agreed .. we might elect one implementation as a reference implementation, but more important is that we propose interfaces, a guideline for how to interpret these interfaces and a test suite to check for compliance.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
> Just realized i forgot cookies.
If you're taking this approach, you will find that you probably forgot a lot of HTTP features :)
If you want to keep things simple, I'd strongly suggest focusing on the following:
1. Request message
- http method
- url
- http version
- headers
- stream for body
2. Response message:
- http status code
- human-readable status
- http version
- headers
- stream for body
Keep in mind that multiple headers can be set with the same name, so a key-value list for
headers may not cover all the use cases.
Using these basic components, you can represent (as far as i know?) any http message.
Anything can be implemented with these components. Cookies would not be an issue, for instance.
Utility objects and classes could be used to aid constructing these headers and deliver them.
These guidelines as a basis, this would allow me:
1. To also wrap the request and response object in my current PHP process.
2. Create a custom client that's capable of asynchronous requests through libevent
3. Create a client that gives me multiple Response objects for every hop in a case of redirects, or a situation where HTTP/1.1 100 Continue is returned.
Your simple client may well be good enough for your use-cases, but in order for something like
this to be successful, it'd be important to create something that doesn't require people to
use other tools as soon as they need anything more complex.
Evert
> Your simple client may well be good enough for your use-cases, but in order for something like
> this to be successful, it'd be important to create something that doesn't require people to
> use other tools as soon as they need anything more complex.
why?
how is not covering the more complex cases going to be a reason to not adopt this for the simple cases?
As a user needing a simple HTTP client, I agree.. no reason to use something more complex if you don't need to.
If you are a provider of an HTTP client (such as Symfony), I'm sure you would agree that you wouldn't want to provide an incomplete client.
Evert
incomplete client? implementing in interface does not preclude you from adding other methods. so i dont see you issue at all.
and there can be other higher level standards that build on this simple interface.
I'm referring to the proposal on github. My point was that it's too simple, and best to first focus on just the Request and Response messages before attempting to define the client.
The current proposal does not have a Request interface, but just a simple set of arguments for making requests.
Was there a miscommunication?
Evert
Apparently so, since i understood you are saying that people wouldnt implement this interface, because its too simple.
Now as for Request/Response, I agree it would be great to also standardize these, but its going to be much harder and the discussion can run in parallel.
As for Benjamin's comment about pecl http: I totally agree that its a good idea to bring Michael into this discussion (actually one of the first things I did after the PR was opened was to ping him on IRC). That being said, we are discussing interfaces here and only implementations in so far as to ensure that the interfaces make sense once they are implemented. Furthermore if possible it is of course also nice to ensure compatibility with existing libs, but as there are already so many, the risk is high that it will just alienate the authors of the given libs if we pick a "favorite".
hm, maybe it makes more sense to focus on pecl_http getting a sane OOP api before it goes into PHP core and until then live with the HTTP client dilemma we have in userland?
hm, maybe it makes more sense to focus on pecl_http getting a sane OOP api before it goes into PHP core and until then live with the HTTP client dilemma we have in userland?
On Sat, Mar 24, 2012 at 7:01 PM, Lukas Kahwe Smith <m...@pooteeweet.org> wrote:
why?
On Mar 24, 2012, at 13:59 , Evert Pot wrote:
> Your simple client may well be good enough for your use-cases, but in order for something like
> this to be successful, it'd be important to create something that doesn't require people to
> use other tools as soon as they need anything more complex.
how is not covering the more complex cases going to be a reason to not adopt this for the simple cases?
--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
To post to this group, send email to php-st...@googlegroups.com.
To unsubscribe from this group, send email to php-standards+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/php-standards/-/uTPxNJwxz0QJ.
To unsubscribe from this group, send email to php-standard...@googlegroups.com.
To suggest a course of action that appears to have been fruitful with PSR-1: Compile a list of known HTTP request/response/client libraries, examine them for commonalities, publish the results, and go from there.
Guzzle, Buzz, ZF, Solar (and soon Aura), Symfony, Lithium, Cake, PECL HTTP, etc. all have HTTP request/response classes. They'd be the likely targets for research.
That way at least we have an idea of what people are *actually* doing, and not be limited to our own ideas of what we *think* people *ought* to be doing.
--
Paul M. Jones
http://paul-m-jones.com/
If we feel it helps, I can ask someone from the httpbis group to provide input too.
We should be a bit further ourselves though :)
Evert
--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
To post to this group, send email to php-st...@googlegroups.com.
To unsubscribe from this group, send email to php-standard...@googlegroups.com.
2. API: I didn't include a Request object as i think its not really necessary. The proposal is expclicitly very simple.
/* PSR-HTTP-Client */use Whizbang\Client as PsrClient; // implements PsrClientInterfaceuse Whizbang\Request as PsrRequest; // implements PsrRequestInterface$psrClient = new PsrClient;$psrRequest = new PsrRequest();(PsrResponseInterface) $psrResponse = $psrClient->makeRequest($psrRequest);/* PSR-HTTP-SimpleClient */use Whizbang\SimpleClient as PsrSimpleClient; // implements PsrSimpleClientInterface$psrSimpleClient = new PsrSimpleClient;(PsrResponseInterface) $psrReponse = $psrSimpleClient->makeSimpleRequest(/* specialized set of simple arguments */);
Should the http client be bound to a host? so that $url is not containing a host? Or should the client wiggle this itself?
--
You received this message because you are subscribed to the Google Groups "PHP Standards Working Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/php-standards/-/CWSymx3hW2wJ.
Assuming this proposal comes to fruition, what's the expectation on existing HTTP clients? Are users expecting breaking changes, adapters, or something else?
interface ClientInterface
{
function send(RequestInterface $request, MessageInterface $response);
}
I do not agree with the Client/SimpleClient distinction.
namespace Fig\Psr\HttpClient;interface RequestInterface{