On Wed, Oct 15, 2014 at 11:19 AM, Dracony <
draco...@gmail.com> wrote:
> To me the IncomingRequestInterface also seems a bit over the top.
> Though I totally understand the rationale behind it, but it looks like it
> would fit more as an RFC for the actual language rather an interpolability
> interface.
> Most frameworks have their own ways of representing the incoming HTTP
> request, and it's usually somewhere near the frameworks kernel, and not much
> stuff interacts with that interpretation directly.
Um, actually, not true, and that's why the IncomingRequestInterface
exists. Most modern frameworks pass around the request object (to
routers, to controllers, to events, etc.). And friction occurs if you
try to mix-and-match code from one framework to another when such
objects are involved.
As a case study: in zf-oauth2, we consume oauth2-server-php. In order
to do so, we need to invoke a controller from the latter -- which
means passing a request and response pair. Of course, we already have
our own -- but now we need to marshal instances for oauth2-server-php,
and ensure that all the incoming data is in the correct format and
properly injected. In particular, the body content is problematic --
because php://input is read-once prior to PHP 5.6. And then we need to
grab stuff out of the returned response and determine (a) what to do
with it, and (b) how to stuff it into our own.
Having a common interface for getting at these details would mean we
could pass our request and response pair directly, without any
translation layer.
Also, consider situations such as Apigility, where you may want to
expose code from your application written in Symfony, or Laravel, or
PPI, etc -- having common request/response interfaces would simplify
this greatly. (Right now, you have to write bridges for each different
framework you want to delegate to.)
All of this is in the http-message-meta.md document. Evidently folks
are not reading the meta documents though, because the same arguments
keep occurring.
> If this was a core PHP feature, like instead of having all those
> superglobals I could just IncomingRequest::getInstance ( ) or whatever, that
> would be so much more awesome and useful.
> On the other hand perhaps including it in a PSR will be a nice step towards
> actually including it in PHP.
That's really the point. I want to see HTTP messages as primary,
supported citizens of PHP -- and this includes abstraction around the
incoming request data, too -- as it would deprecate monolithic
frameworks and promote the idea of smaller, targetted code that
interacts with them in order to perform common workflows. (E.g.,
content negotiation, cache control header manipulation, etc.)
If this proposal is accepted, and becomes widely adopted, perhaps we
can then push it into the PHP core. In the meantime, we'd have a
wonderful forward-compatible emulation in userland.
> But it might be better off as a separate PSR, since it has less to do with
> the HTTP protocol and more with PHP superglobals.
Several have suggested this. I've chosen to keep it as part of the
HTTP Message PSR because the actual interface is relatively
lightweight (particularly with the changes I've incorporated today),
and because the HTTP messages by themselves are primarily useful for
clients -- while I want to see greater interop amongst those writing
server-side code in particular.
--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/