数か月前、HTTP/2は RFC754 として公開されました。これは既存のREST HTTP/1.1に構築されたAPIにどのように影響しますか
wikipedia に従って、HTTP/2は新しい機能を追加しました。これらの新機能をどのように活用できますか?
この質問を自由に改善してください。
ありがとう。
HTTPの主要なセマンティックは、HTTP/2でも保持されています。これは、GET
、POST
など、HTTP methods
、およびURIs
などのリソースを識別するHTTP headers
がまだあることを意味します。
HTTP/2でHTTP/1.1に関して変更されたのは、HTTPセマンティクス(たとえば、「ホスト上のPUT
リソース/foo
domain.com
」が転送される方法です。ワイヤー。
この観点から、REST HTTP/1.1で構築されたAPIは、アプリケーションに変更を加えることなく、以前と同様に透過的に動作し続けます。アプリケーションを実行するWebコンテナは、アプリケーションに代わって、通常のHTTPセマンティックへの新しいワイヤ形式が適用され、アプリケーションがワイヤ経由でHTTP/1.1またはHTTP/2を介して転送されたかどうかに関係なく、アプリケーションはより高いレベルのHTTPセマンティックを表示します。
HTTP/2ワイヤ形式は(特に多重化と圧縮のため)より効率的であるため、REST HTTP/2上のAPIもこの恩恵を受けます。
HTTP/2に存在するもう1つの主要な改善であるHTTP/2 Push
は、相関リソースの効率的なダウンロードを対象としており、おそらくRESTユースケースでは役に立たないでしょう。
HTTP/2の一般的な要件は、TLS経由で展開することです。これには、デプロイヤがhttp
からhttps
に移動し、それをサポートするために必要なインフラストラクチャをセットアップする必要があります(信頼できる機関から証明書を購入、更新など)。
HTTP/2仕様は、意図的にアプリケーションプログラマーに新しいセマンティクスを導入しませんでした。実際、主要なクライアント側ライブラリ(iOSのNSUrlSession、AndroidのOkHttp、React Native、ブラウザ環境のJS))は、開発者として透過的にHTTP/2をサポートします。
単一のTCP接続を介して多くの要求を多重化するHTTP/2機能により、 request batching などの過去に実装されたアプリケーション開発者の一部の最適化は廃止され、カウンターにさえなります-生産的。
プッシュ機能は、イベントを配信するために利用される可能性が高く、一部のアプリケーションではポーリングやWebソケットを置き換えることができます。
HTTP/2のサーバープッシュ機能のREST APIに適用できるアプリケーションの1つは、予想されるリクエストを待つのではなく、クライアントに事前にプッシュすることにより、リバースプロキシレベルでレガシーアプリケーションを高速化する機能ですつまり、ログインリクエストが完了した直後に、ユーザープロファイルへの回答と他の一般的なAPI呼び出しをプッシュします。
ただし、Pushはサーバーとクライアントのインフラストラクチャ全体にまだ広く実装されていません。
主な利点は、リソースへの参照を保持するハイパーメディアRESTful APIのサーバープッシュです。多くの場合、/post/12
などの絶対ドメイン依存URLです。
例:GET https://api.foo.bar/user/3
{
"_self": "/user/3"
"firstName": "John",
"lastName": "Doe",
"recentPosts": [
"/post/3",
"/post/13",
"/post/06
]
}
HTTP/2プッシュを使用して、クライアントが将来特定のGET要求を実行する可能性が高いとサーバーが認識している場合、ブラウザキャッシュを先制的に設定できます。
上記の例では、HTTP/2サーバープッシュがアクティブで適切に構成されている場合、/post/3
とともに/post/13
、/post/06
および/user/3
を配信できます。これらの投稿の1つにGETs
を連続して送信すると、応答がキャッシュされます。また、 キャッシュダイジェスト ドラフトにより、クライアントはキャッシュの状態に関する情報を送信でき、不要なプッシュを回避できます。これは、Hypermedia駆動のAPIの場合、そのような埋め込みボディよりもはるかに実用的です [〜#〜] hal [〜#〜] 。
ここでの理由の詳細: REST今日の埋め込みの問題とHTTP/2でどのように解決できるか 。