サーバーからリソース表現を取得する際に、いくつかの追加情報を取得する必要がある場合があります。私が意味する情報は、固有のエラーメッセージ (「猫が道路を横切ったため、要求された犬を取得できません!」) など、具体的にはリソースを指します。
私は調査を行いましたが、それを行うための最もRESTful な方法について少し混乱しているように感じています (REST の HTTP 実装について言及していることは言うまでもありません)。正直なところ、「標準的な」採用方法はないように感じますが、さまざまな意見を聞きたいです。
これが私のものです：
HTTP ヘッダーを使用- これを行う主な理由は、HTTP が既にエンベロープを提供しているためです。なぜプロトコルのエンベロープ内に新しいカスタム エンベロープを挿入するのでしょうか? さらに、HTTP はアプリケーションプロトコルであり、アプリケーションの対話をサポートすることになっています。ただし、新しい情報をヘッダー セクションにプッシュすることには 2 つの欠点があります。1 つ目は、カスタムの内容を含めることになり、これは「統一されたインターフェイス」の推奨事項にあまり準拠していません。さらに、標準ヘッダーを見ると、それらの大部分が接続と情報交換 ( Accept、Connection、など)Forwardedに関連しHost、非常に不可知User-Agentな方法でペイロードを参照していることがわかります( 、、Content-TypeIf-MatchEtagなど）。リソース固有の情報には不適切なコンテキストのようです。
エンベロープの使用- この戦略が優れている理由は 2 つあります。非常に柔軟であり、クライアントの 99% がメタ情報を参照するために使用される場所です。理論的な観点から、オブジェクトを含むエンベロープはリソースの表現であると言えます。car オブジェクトが要求されると、サーバーはその要求に対して最も意味のある表現を自由に提供できます。悪い点は、REST に完全に反対する SOAP アプローチに非常に似ているように聞こえることです。
調停- 私の考えは実用的であることです: ヘッダーのカスタマイズを乱用せず、代わりにあなたが持っているものを使用してください. HATEOAS を実装する必要がある場合は、Linkヘッダーを使用してください。キャッシュ用のリソースを表す必要がある場合は、 を使用してくださいETag。高度なカスタマイズが必要な場合は、エンベロープをリソースとして使用し、エンベロープ セクションで必要なメタ情報を提供します。