2015年5月18日06:00時点で、 PSR-7（HTTPメッセージインターフェイス）が承認されたことをお知らせいたします。
UPD。 「例の中のPSR-7」の良い翻訳 。
PSR-7への道
PSR-7への道は長く曲がりくねっていました。 それはすべて、2012年夏にBenjamin Eberleiが作成したHTTPクライアントで作業するための提案案から始まりました。
開始する
クリス・ウィルキンソンはこのアイデアを取り上げて正式なドラフトを作成し、後にPSR-7になりました。 HTTPメッセージを操作するための独自のインターフェイスを開発しました。 編集者としての時間の間に、クリスはURIのコンパニオン提案のコンパイルも開始しましたが、PSRに入ることはありませんでした。 PSR-7はかなりの期間、特にヘッダーをメッセージの一部として保存するという側面のセクションで洗練され、2つのタイプのメッセージ間の共通機能を要求と応答の違いの説明とともに記述する
MessageInterface
ありました。
ある時点で（グループのアーカイブで正式な発表をまだ見つけていませんが）、リレーはMichael Dowlingに引き渡されました。 彼の最大の貢献は、ストリームの形式でメッセージ本文をモデル化する提案でした。 実装はかなり議論の余地があるように思われ、最終的にそのような決定が行われた理由と理由の詳細な説明を含む大きな投稿になりました。 最高だと思います！ すべての優れた言語には、メッセージの本文をストリームとしてモデル化する優れたHTTP抽象化があることを確認しました。これにより、非同期で作業できるようになりました（残念ながら、PHPでは長い間サポートされていませんでした）。また、大きなメッセージが使用可能なすべてのメモリを消費しないようにします。 PHP自体には、ストリーム形式のメッセージモデル（
php://input
および出力バッファー）があり、これが最も自然なパスです。
エフェクトnode.js
この投稿の登場後まもなく、 node.jsに非常に夢中になり、httpの処理に関してさまざまなモジュールがどのように機能するかに驚きました。 これは、主にhttpプロトコルの適切に設計された抽象化がデフォルトで存在するためです。これは、ほぼすべての場所でhttpで同じ作業を使用できるという形で優れた副作用をもたらします。
おそらくnode.jsで最も一般的なフレームワークであるExpressに同梱されている中間ライブラリであるConnectを移植することにしました。 しかし、これを行うと、克服できない障害に遭遇しました。httpの抽象化です。
もちろん、すべてのフレームワークにはHTTP抽象化があります。 私は、Zend Frameworkを対象としたものに密輸しました。 多くのPHP開発者と同様に、これらの概念がどのように機能するかを理解したいのですが、特定のhttp抽象化の選択はプロジェクトのさらなる発展に影響を与える可能性があります。 そして、PSR-7とストリームに関するMichaelの投稿を思い出しました。 そのとき、「PSR-7を目指す必要がある！」という理解が得られました。
問題は実装の欠如でした。
そのため、週末には元のバージョンが実装されました。 マイケルの出版から数日後、彼は時間不足のためにPSR-7を放棄するという噂が広まり始めました。
私の来る
数週間の議論と厳しい考えの末、私はドラフトを拾い上げ、それを地面から移動させようと決心しました。 Phil SturgeonとBeau Simensenは、スポンサーおよびコーディネーターとして継続することに同意しました。 そして、編集者としての在職期間が始まりました。
これは興味深い挑戦になりました。 私が始めたとき、スレッドの使用に関する議論はまだ終わっていませんでした。 マイケルの主張の根拠を急いで増やして、まさにそのような決定を支持し、それを擁護することに同意するのか、本当に良い選択肢があるのかを考えなければなりませんでした。
修正が必要な別の側面が発見されました：メッセージはクライアント側で完全に機能しましたが、サーバーは失われていました：ユーザーは文字列引数をリクエストするためのURIを解析し、メッセージ本文とCookieのヘッダーを手動で解析する必要がありました...そして、一般的に、私は結論に達しましたnode.jsのようになります。すべてを手作業で行うか、すべての作業をマイクロフレームワークにダンプします。
深いところのどこかで、もっとうまくやれるという気持ちがありました。 このように、
ServerRequestInterface
が誕生しました。これは、PHPがうまく機能しない場合（たとえば、POST以外のリクエストに対して
$_POST
が満たされなかったり、特定のメディアタイプのないPOSTリクエストの場合）。
進捗状況
2014年12月に辞任し、Philは彼を辞任し、追加のスポンサーを探しました。 Paul Jones （ Paul M Jones ）は、彼の立候補を親切に提案しました。
標準のサーバー側の部分は何度も批判されてきましたが、最終的にはこれについて合意に達しました。 多くの関係者がオブジェクトの可変性について話しました。 1月に、私はオブジェクトの不変性と仕様の応用概念について深く理解しました。 その結果、副作用のない非常に信頼性の高いものが得られ、状態の変化に起因する可能性のある問題のカテゴリ全体が排除されました。 しかし、コミュニティはきしみをもってこの決定を下しました。彼らは実際の例を見るまで落ち着きませんでした。
コンポーネントのURIを整理するために
UriInterface
も導入されました。 スキーム、パス、ホストなどを取得するために、URIを解析する必要があることが非常に多いことがわかりました。 かなり退屈で退屈な職業で、エラーに満ちています。 抽象化が存在すると、すべてがその場所に配置されます。 それは後のURI提案と互換性があるように設計されており、クリス・ウィルキンソンが以前に行ったアプローチから大部分を借用しています。
投票
この時点で、投票用のドラフトを作成することにしました。 最初の結果は非常に肯定的で、帽子のように見えました。 しかし、2週目のどこかで、このオファーを初めて見た人々がやってきました。 開発者の詳細に対する腐食性の注意に匹敵するものは何もなく、多くの欠陥があることを理解するのに役立ちました。 その中でも重要なのは、URIとホストヘッダーの関係を説明するための作業があまり行われず、ファイルのアップロードがうまく機能しなかったことです。
採択の約24時間前に投票をキャンセルすることで、設計段階に戻りました。 Bernhard Schussekは、最終的に含めたファイル転送の抽象化に優れた正当性を提供し、以前のバージョンを簡素化するためにURIとホストの関係にも取り組みました。
そして、これにより私たちは2番目の投票に至り、それが論理的な結論に達しました：新しいPSRが採用されました！
ありがとう
編集者であり、大部分は著名な人物として、私はこれが多くの人々による長年の仕事の結果であったことに注意するしかありません。 そして特に感謝したいのは：
- Larry Garfield （ Larry Garfield ） 、いくつかのプロジェクトでPSR-7をテストし、使用の見通しについてのフィードバックを受け取ることができました。
- 最終的に規格の採択に反対票を投じたが、素晴らしいレビューを提供し、ドラフトの全期間を通じて議論に参加したEvert Pot。 彼の助けは非常に貴重でした。
- フィル、ボー、ポール。私のティラデスを読んでくれました。過去数ヶ月間、フラストレーションと自信に満ちていました。