PSR-7 adopted

I am glad to announce that as of 06:00 May 18, 2015, PSR-7 (HTTP Message Interfaces) has been accepted!

UPD. A good translation of "PSR-7 in the examples . "

Road to PSR-7

The path to the PSR-7 was long and winding. It all began in the summer of 2012 with a proposal for working with HTTP clients for authorship Benjamin Eberlei, during which other participants suggested that perhaps a small standard for http messages was what would solve all the problems.

Start

Chris Wilkinson ( Chris Wilkinson ) picked up the idea and created a formal draft, which later became PSR-7. It developed the original interface for the operation of HTTP messages. During his tenure as editor, Chris also began drafting a companion URI proposal, but it never entered the PSR. PSR-7 was polished for a considerable time, especially the section on saving the header as part of a message and had a MessageInterface that describes the common features between the two types of messages describing the differences between the request and the response.
')
At a certain point (I don’t know for sure, I still haven’t found any formal announcement in the archives of the group) the baton was passed to Michael Dowling . His biggest contribution was the proposal for modeling the message body as a stream. The implementation seemed rather controversial, and eventually it emerged into a large post with a detailed description of why and why such a decision was made. In my opinion, this is amazing! I checked that every good language has an excellent HTTP abstraction that simulates the message body as a stream: it allows you to work asynchronously (which, alas, was not supported in PHP for quite a long time), and ensures that large messages will not eat up all the available memory. PHP itself has a stream message model ( php://input and output buffer), this is the most natural way.

The impact of node.js

Shortly after the appearance of this post, I played a lot with node.js and was amazed at how different modules work in terms of handling http. This is largely due to the default presence of a well-developed abstraction of the http protocol with an excellent side effect in the form of the possibility of using the same work with http almost everywhere.

I decided to port Connect , the intermediate library that comes with Express , perhaps the most common framework in node.js. But doing this, I ran into an insurmountable obstacle: http abstraction.

Of course, every framework has an HTTP abstraction. I even contribut in one, intended for Zend Framework. The line of thought was this: I want to figure out, like many PHP developers, in these concepts, to find out how it works, but the choice of a specific http abstraction can influence the further development of the project. And then I remembered Michael's post about PSR-7 and streams. It was then that the understanding came - “I need to aim at the PSR-7!”

The problem was the lack of implementation.

So, over the weekend was implemented the original version. About a couple of days after Michael’s publication, rumors began to circulate that he was about to abandon PSR-7 due to lack of time.

My arrival

After several weeks of discussions and hard thinking, I decided to pick up a draft and try to get it off the ground. Phil Sturgeon and Beau Simensen agreed to continue as a sponsor and coordinator. And so began my time as editor.

It has become an interesting challenge. When I started, the thread usage debate has not abated yet. It was necessary to urgently build up the basis of Michael's arguments in favor of just such a decision and think whether I agree to defend him or indeed there are better options.

There was another aspect that needed to be eliminated: the messages worked perfectly for the client side, but the server was a loser: users had to parse the URI to request string arguments and parse the message body manually, and the headers for cookies, and ... well, I came to the conclusion , which is obtained as in node.js: either you do everything by hand, or you dump all the work on the microfragm.

Somewhere in the depths there was a feeling that we could have done better. Thus, a ServerRequestInterface was born that provides access to data in the PHP superglobal variables, as well as giving some necessary abstractions to fill in the data for when PHP does not work well (for example, you cannot get a full $_POST for non-POST requests or for POST requests without specific media types).

Progress

December 2014 was gone and Phil with him resigned, leaving me in search of an additional sponsor. Paul Jones ( Paul M Jones ) kindly offered his candidacy.

The part of the standard relating to server requests many times caused a lot of criticism, but in the end we reached a consensus on this issue. Many worried people spoke about the mutability of objects. In January, I was deeply immersed in an understanding of the immutability of objects and applied concepts of specification. As a result, we got something very reliable, without side effects, eliminating entire categories of possible problems due to the changing state. But this decision was made by the community with difficulty, the guys did not calm down until they saw real examples.

UriInterface was also introduced to order the component URIs. We found that very often you have to parse the URI to get things like the scheme, the path, the host, etc. Pretty tedious and tedious task, fraught with errors. The presence of abstraction put everything in its place. It is designed in such a way that it can be compatible with later URI proposals and largely borrowed the approaches made earlier by Chris Wilkinson.

Voting

At this moment we decided to put the draft to the vote. The initial results were very positive and it looked as if it was a hat. But somewhere in the second week, people began to arrive who saw the offer for the first time. Nothing compares to the corrosive attention of developers to the details, it was they who helped to understand that there are a number of flaws. The key among them was that we didn’t do a great job of describing the links between URIs and host headers; the file upload wasn’t well developed.

By canceling the vote about 24 hours before the adoption, we returned to the design stage. Bernhard Schussek ( Bernhard Schussek ) provided some excellent rationales for the file transfer abstraction, which we eventually included, also worked the URI / Host relationship to simplify with respect to the previous version.

And this led us to re-voting, which in turn came to a logical conclusion: the new PSR was adopted!

thank

I, as an editor and a largely public person, cannot but note that this was the result of many years of work by many people. And especially I want to thank:

• Larry Garfield, who tested PSR-7 on some projects, and provided feedback on prospects for use.
• Evert Pot ( Evert Pot ) , who ultimately voted against the adoption of the standard, but provided fantastic reviews, taking part in the discussion throughout the life of the draft. His help was invaluable.
• Phil, Bo, and Paul, who read my tirades, full of frustration and self-doubt over the past few months!