RESTサービスの一意のリクエストIDのHTTP応答ヘッダー
RESTサービスの場合、すべての応答で一意のリクエストIDを送りたいので、内部プロジェクトのデバッグだけでなく、将来サービスを使用する可能性のあるサードパーティにサポートを提供するのにも役立ちます。
すべてのREST要求が応答本文を生成する必要があるとは限らないため、応答ヘッダーを使用する必要があると判断しました（多くの場合、下位レベルREST APIは純粋にステータスコードと説明の利点があります）が、このリクエストIDを送り返す必要があります。
可能であれば、unlikelyであるHTTP応答ヘッダーを使用して、途中でプロキシが取り除かれることを確認します。
多くのクライアントはモバイルデバイスであり、クライアントとサーバー間の「興味深い」ネットワークトポロジにバインドされているため、これは非常に重要です。
ただし、同じサービスが、自社のファイアウォール/プロキシを使用して他の企業にも販売される可能性があります。
このため、よく知られているヘッダーを優先して、カスタム応答ヘッダーを使用するという考えを根本から排除しました。
私の現在優勝している有名なヘッダーはETagヘッダーですが、ほぼ正しいですが、完全ではありません-ETagはリソース用であり、リクエストではありません（つまり、同じリソースに対する2つの別々のリクエストは、合法的に同じETagを返します）。さらに、それを使用する場合、それ以外にはエンティティタグ付けを実行できないことを意味します。
誰か良いアイデアはありますか？
更新
Pragmaヘッダーは表示されるようですが、使用できますが、Asp.Net WebAPI内での書き込みに問題があります。 SOに関する関連質問です 。
ヘッダーは使用せず、標準化された本文を使用します。たとえば、すべての本文をJSONにして、IDフィールドを含めることができます。プラットフォーム全体で標準化されている限り、動作することが保証されています。
カスタムヘッダーは削除されるリスクがあるため、使用しません。完全に適合するヘッダーがわからないため、標準ヘッダーは使用しません（たとえば、あなたが言及するETagは、ファイルの変更とキャッシュキーの決定に使用されます）。
Herokuチームのガイドラインをご覧ください。 Etagsなどの他のものの中で、それらはヘッダーのRequest-Idを提案します。私たちは、これらのガイドラインのほとんどを意味のある場所に実装することを目指しています。
リクエストIDを使用してリクエストをトレースする
各API応答にRequest-Idヘッダーを含め、UUID値を入力します。サーバーとクライアントの両方がこれらの値をログに記録すると、要求のトレースとデバッグに役立ちます。
https://github.com/interagent/http-api-design/blob/master/README.md