-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make HTTP Client a PSR standard #51
Comments
I am not against the idea. However, I think it is better to have a complete idea and present that to the group. A few people working on something and then discussing it as a whole is better IMHO and I think the FIG has proven that the more people try make ideas come true, the more times the whole proposal will be rewritten from scratch. IvoryHttpAdapter is already a name in the PHP economy, PHP HTTP will be its successor, so I would argue with the "yet another HttpInterface" sentence. |
agreed and @weierophinney just replied about the same understanding to
me on twitter. maybe a point for the "about" section in the README (like
"If one day there is a PSR standard for HTTP clients or middleware that
can replace this library, we will deprecate the library in favor of the
PSR standard")
|
Will this compatible with the PSR https://github.com/shadowhand/fig-standards/blob/http-factory/proposed/http-factory/http-factory.md? Once it is accepted of course. |
PSR-15 is about the request and response factories, not about the client. imho we will deprecate our factory interfaces in favor of PSR-15 once its released. the client is not tied to the factories and would still make sense to be standardized. |
@dbu I don't know if this has changed since 2016, but the HTTP Factories draft is designated as PSR-17. |
Im working on it. Expect some updates before end of July. |
PSR-18 is out \o/ |
only cache downloaded packages
This is not an immediate thing, but more of a discussion about the future:
liuggio suggested to propose the client as PSR. i think this is a viable idea, but will take more time. see also the discussion on PSR that liuggio referse to.
i think at this point we should just release what we have, as it will improve the situation and bring PSR-7 for generic HTTP Client consumers this year.
but we should try to get pinged/involved with the PSR discussion when they pick this topic up again. looking at the interfaces they throw around, i see there is little difference at the core between a server and a HTTP client: you have a request and want a response. whether the implementation produces the response itself or does a web request is more of an implementation detail. though the situation you use one or the other will often look different, and e.g. the kind of errors that can happen look different...
with the time just PSR-7 took, i think it will take a long time to get a PSR for this topic released and we should not wait, rather go with this abstraction and gather experience that can help build the PSR.
/cc @weierophinney, @liuggio
The text was updated successfully, but these errors were encountered: