RESTサービスの一意のリクエストIDのHTTP応答ヘッダー


8

RESTサービスでは、すべての応答で一意のリクエストIDを送り返したいと思います。内部プロジェクトのデバッグに役立つだけでなく、将来サービスを使用する可能性のあるサードパーティにサポートを提供する場合にも役立ちます。

すべてのRESTリクエストがレスポンスボディになる必要があるわけではないため(多くの場合、低レベルのREST APIはステータスコードと説明のみを利用します)、このリクエストを送り返す必要があるため、レスポンスヘッダーを使用する必要があると判断しました。 ID。

可能であれば、途中でプロキシによって取り除かれる可能性低い HTTP応答ヘッダーを使用するようにします。

多数のクライアントがモバイルデバイスであり、クライアントとサーバー間の「興味深い」ネットワークトポロジにバインドされているため、これは非常に重要です。

ただし、同じサービスが、自社のファイアウォール/プロキシを使用する他の企業にも販売される可能性があります。

このため、よく知られているヘッダーの代わりにカスタム応答ヘッダーを使用するという考えを根本的に覆いました。

私の現在の優勝既知のヘッダーはETagヘッダーですが、それはほぼ正しいですが、それは完全ではありません- ETagはリソース用であり、リクエストではありません(つまり、同じリソースに対する2つの別々のリクエストは合法的に同じを返しますETag)。さらに、それを使用すると、エンティティタグを他の目的で実行できないことを意味します。

誰か良いアイデアはありますか?

更新

Pragmaヘッダーは使用されているように見えますが、Asp.Net WebAPI内での書き込みに問題があります。 SOに関する関連質問です。

回答:


4

私は標準化されたボディを使用し、ヘッダーは使用しません。たとえば、すべての本文をJSONにして、IDフィールドを含めることができます。プラットフォーム全体で標準化されている限り、動作することが保証されています。

カスタムヘッダーは削除されるリスクがあるため、使用しません。完全に適合するヘッダーがわからないため、標準ヘッダーは使用しません(たとえば、あなたが言及したETagは、ファイルの変更とキャッシュキーの決定に使用されます)。


2
はい、それはオプションです。しかし、このようなエンベロープされた応答について何かがハッキーに感じられます。文字列を返すjson操作について考えます。現在は2つのメンバーを持つ型を返しているため、クライアントはデータを取得するためにさらに多くの作業を行う必要があります。あまり落ち着かない!私はそれをするかもしれない仕様でヘッダーを見つけました、私は答えを投稿しています...
Andras Zoltan

実際、私はそうではありません。「message-header」の仕様の定義を特定のヘッダーであり、BNFルールではないと誤って解釈したようです。うーん...
アンドラス・ゾルタン

1
私のすべてのプロジェクトでは、本文に構造化データを使用しています。プレーンな文字列は使用していません。将来的には、新しいデータを追加する必要があることが多いからです。JSONは標準的なアプローチであり、jQueryはAJAX呼び出しから戻るときに、応答本文を自動的にJSオブジェクトにします。すべての呼び出し/応答を独自の関数でラップして、構造を一貫して処理することもできます。
マットS

0

Herokuチームのガイドラインをご覧ください。Etagsなどの他のものの中で、それらはヘッダーのRequest-Idを提案します。私たちは、これらのガイドラインのほとんどを意味のある場所に実装することを目指しています。

リクエストIDを使用してリクエストをトレースする

各API応答にRequest-Idヘッダーを含め、UUID値を入力します。サーバーとクライアントの両方がこれらの値をログに記録すると、要求のトレースとデバッグに役立ちます。

https://github.com/interagent/http-api-design/blob/master/README.md


1
カスタムヘッダーの問題は、プロキシによって正当に取り除かれる可能性があることです。最後に、Pragmaヘッダーを使用しました。これは、独自のカスタムデータを送信するメカニズムを提供するためのものであり、インフラストラクチャbodが明示的に設定しない限り、プロキシによってデフォルトで削除されることはありません。
Andras Zoltan 14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.