私は最近、着信 HTTP リクエストへの応答をできるだけ早く開始する必要があると主張する複数の講演に出くわしました。
応答コード 200 を送信して HTML ページのレンダリングを開始する状況をイメージしてみましょう。本体を構築すると、さまざまな db クエリからデータが流れ込み、突然エラーが発生します。この時点で考えを変えるには少し遅すぎます。
または、より実用的な例:
多くのデータを配信する可能性のある API を提供しています。高速に保つために、プロジェクト関数を介して DB 接続からデータをストリーミングし、ソケットに直接書き込むストリーミング JSON エンコーダーにデータをストリーミングします。うん、何かがうまくいかない。DB 接続が切断され、再接続の試行がタイムアウトします。10 万個の JSON オブジェクトをフラッシュしましたが、結果セットは実際にはそれよりも大きくなりました。
HTTP 応答の途中で優雅に終了する良い方法はありますか?
HTML の場合、人が読める情報をいつでも出力できます。そして、API では{ "results": [ /* payload goes here */ ], "error": { /* error information */ } }、エラーがペイロードの後に書き込まれるため、1 回で応答できます。これは問題ありません。しかし、理想的には、HTTP プロトコルに組み込まれたものを使用したいと考えています。200 と言ってからエラーを出すのは奇妙に思えます。より良い方法はありますか？