On 29 Jan 2015, at 12:18, Crypto Compress <
[email protected]> wrote:
* Why should we have our own HTTP API and not follow PSR-7?
possible points:
- PHP-FIG propose no implementations; pecl_http does
- native implementations should be faster
I don’t see how that’s relevant: I’m talking here about the API, not the implementation. Why should PHP’s HTTP API not be PSR-7?
- PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script
Also irrelevant, there’s no reason it couldn’t use PSR-7’s API.
- PSR-7 is a moving target; pecl_http exists for ten years
Fair point.
- PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?)
Not necessarily true.
--
Andrea Faulds
http://ajf.me/
In my rainbows and ponies vision of the future, it would go something like this:
1) PSR-7 is approved. People use it. People love it.
2) Internals makes internal definitions of the interfaces from PSR-7, renamed to a PHP namespace but otherwise identical. Eg:
\Php\Http\Message
\Php\Http\Request
\Php\Http\Response
\Php\Http\ServerRequest
FIG makes available an alternate set of interfaces that are PSR-7 but extent the internal ones for type hint compatibility.
Someone (FIG, internals, me?) makes a user-space definition of the new internals interfaces as a BC layer.
3) Internals improves its userspace stream APIs such that the StreamInterface from PSR-7 can be retired completely. (It exists almost entirely as a way to avoid dealing with the PHP-native stream APIs.)
4) Internals adds a function/routine/thing to spawn a ServerRequest that is equivalent to the user-space code to create a PSR-7 ServerRequest out of the superglobals. It is, of course, faster than doing in userspace and also more standard. Internals also adds a "send this response object to this stream (default stdout)" routine.
5) Everyone switches over to using the Internals-named interfaces and ServerRequest builder. Because the interface is the same aside from the name this is about a 5 minute task per project and could be done by a small shell script.
6) Internals build a simple HTTP client that uses \Php\Http directly. It's probably not as powerful as Guzzle et al but easily extensible. Because user-space clients are already using those interfaces, that makes swapping the new Internals one in instead is a really easy task. Guzzle et al can convert to being extensions on the core one, all using the common interfaces.
7) The Ewoks, they dance!
I don't expect it will happen exactly like that, of course, but the closer we can get to that sort of chain of events the better I think it will be for everyone.
Note that the interface definition parts are separate from the writing of the HTTP client. I think it's important to address those two separately. SRP applies to RFCs just as much as code. :-)
--Larry Garfield