Replace PSR-7 with a standard HTTP message *implementation*?

370 views
Skip to first unread message

Matthieu Napoli

unread,
May 19, 2016, 2:30:24 PM5/19/16
to PHP Framework Interoperability Group
Hi everyone,

There has been a lot of debates lately about PSR-7 middlewares and the main sticking point is whether or not to pass the response in the middlewares as parameter. The main argument for that is to avoid depending on a specific implementation.

How about releasing a new "PSR-7" (different number obviously) that would be a default implementation? That would solve the middleware problem, and that would be simpler too (no need to find an implementation).

I know some people wished it would have been that way from the beginning, but it's never too late to improve things. Do we need the interfaces? Is there any actual value in having different implementations since PSR-7 objects are value objects? Right now I don't see it and I haven't found anything in the PSR-7 metadocument.

We would have 3 options I guess:

1. write a separate package, deprecate PSR-7 and encourage using the standard implementation only
2. write a separate package that implements PSR-7 interfaces, but deprecate PSR7 and eventually remove completely the interfaces (PSR-X would be the recommended standard)
3. write a separate package that implements PSR-7 interfaces and keep both eternally

I think 3. is easy but would be confusing for everyone: should we type-hint against the interfaces or the implementation? I think everyone will have its opinion on this, and if the interfaces bring no additional value then they are only noise.

1. breaks BC a lot, so it might not be possible.

2. is IMO the best course of action as we have controlled backward compatibility yet a clear goal and best long-term solution.

What do you think?

Matthieu

PS: yes PSR-7 is not that old, but Evert Pot has some interesting words (https://evertpot.com/why-php-fig-matters/) :

> I don’t think we need to try to aim to create an organization that prevents people from making bad decisions. Instead the organization we need is one that allows someone to make that mistake in the timespan of about 5 months instead of 5 years, so room can be created for a new PSR that solves the 80% problem in a less ridiculous way.

And of course I don't think PSR-7 is a mistake ;) I'm just throwing out an idea…

Woody Gilk

unread,
May 19, 2016, 2:45:54 PM5/19/16
to PHP Framework Interoperability Group
On Thu, May 19, 2016 at 1:30 PM, Matthieu Napoli <matt...@mnapoli.fr> wrote:
> That would solve the middleware problem, and that would be simpler too (no
> need to find an implementation).


This argument is based on the premise that something is flawed with
PSR-7 interfaces. That is not the case. There is nothing wrong with
having multiple implementations of PSR-7, just as there is nothing
wrong with multiple implementations of PSR-3. FIG does not create
implementations, it creates interfaces and recommendations.

If you start from the idea that middleware should be creating
responses, you end up in the current mess. If you take the currently
proposed middleware PSR as the right solution, all of these perceived
issues with PSR-7 implementation are a non-issue. To say that 20+
projects all came up with the wrong solution without any formal
recommendation is madness.
--
Woody Gilk
http://about.me/shadowhand

Larry Garfield

unread,
May 20, 2016, 4:15:39 AM5/20/16
to php...@googlegroups.com
I believe there are good use cases for different PSR-7 implementations, but not dozens. For *most* of the object, there's only one reasonable implementation.  There's probably only 1-2 reasonable implementations of the Url object, for instance.  For that reason, most people should still be typing against the interfaces.

I've long been an advocate for option 3; we should have pushed the traits from PSR-3 into their own util package, and we did that for PSR-6 (the cache-util library).  I am fully in favor of FIG offering an http-message-util library that contains the common 90% of PSR-7 implementations; if it also includes some default complete implementations, I won't make a fuss over it at all.

Zend Diactoros is the obvious reference implementation to borrow, but I don't know how MWOP would feel about that and don't want to speak for him.  (Obviously the licensing terms say he couldn't stop us, but it would be quite rude to clone Diactoros for a FIG reference implementation without his blessing.)

--Larry Garfield

Glenn Eggleton

unread,
May 20, 2016, 10:43:18 AM5/20/16
to PHP Framework Interoperability Group
I think this could become a good idea... 

Matthieu Napoli

unread,
May 20, 2016, 1:13:02 PM5/20/16
to PHP Framework Interoperability Group
Thanks Woody, Larry and Glenn for your answers.

In order:

> FIG does not create implementations, it creates interfaces and recommendations.

The FIG creates whatever it wants. Pre-PSR3 there was a discussion on whether the FIG should even define interfaces (http://mnapoli.fr/php-fig-should-define-php-interfaces/).

> To say that 20+ projects all came up with the wrong solution without any formal recommendation is madness.

Maybe we are not understanding each other but the way things are going with PSR-7 most projects are using a de-facto standard implementation (Diactoros).

> I believe there are good use cases for different PSR-7 implementations, but not dozens.

Maybe that would be interesting to list them? If anything that discussion could be useful to improve the PSR-7 meta-document with such examples.

Then if there are, then interfaces make sense. If there aren't then maybe a standard implementation would be more useful (e.g. with the middleware discussion).

Matthieu

Woody Gilk

unread,
May 20, 2016, 1:20:54 PM5/20/16
to PHP Framework Interoperability Group
On Fri, May 20, 2016 at 12:13 PM, Matthieu Napoli <matt...@mnapoli.fr> wrote:
> Maybe we are not understanding each other but the way things are going with
> PSR-7 most projects are using a de-facto standard implementation
> (Diactoros).

This is true right now for server implementations, because Diactoros
was the first out of the gate and provides a complete implementation
[1]. Guzzle also implements PSR-7 but contains no ServerRequest
implementation and therefore cannot be used as a replacement in many
situations.

[1]: There are actually a few other packages that provide a complete
implementation [2], including (oddly enough) Slim. None of these are
nearly as popular as Guzzle or Diactoros.

[2]: https://packagist.org/providers/psr/http-message-implementation

Jonathan Eskew

unread,
May 20, 2016, 8:22:47 PM5/20/16
to PHP Framework Interoperability Group
Guzzle actually provides implementations of ServerRequestInterface and UploadedFileInterface as of version 1.3.0.
Reply all
Reply to author
Forward
0 new messages