HTTPリクエストヘッダーとリクエスト本文には何が含まれていますか？
私はモバイルクライアント用の一連のWebサービスに取り組んでいます。この要件では、すべてのリクエストに一意のデバイスIDを含め、特定のリクエストに格納し、他のリクエストの結果をフィルタリングするために使用する必要があります。
すべてのリクエストに含まれるため、カスタムHTTPヘッダーに含めるよう提案されたため、特定のデータがヘッダーに含まれるか、リクエストボディ。
そのような基準はありますか？
情報が重要な場合は、体の中に入れてください。
どうして？
- プロキシサーバーはヘッダーを変更できます。多くは、知らないヘッダーを取り除くように構成されています。ただし、これは暗号化されていないHTTPを使用する場合にのみ適用されます。 HTTPSを使用する場合、ヘッダーは暗号化されているため、プロキシはヘッダーを変更できません。
- Webサービスを使用する場合、通常は他のデバイス、サービス、ツールとの相互運用性のために使用します。 Webサービスで動作するほとんどのAPIとツールは、リクエストを簡単に変更できますが、カスタムヘッダーを追加することは困難または不可能です。もちろん、これは相互運用性が懸念される場合にのみ適用されます。ただし、気にしない場合は、生のTCPで独自のプロトコルを構築するのではなく、なぜ最初からWebサービスを使用しているのかを自問してみてください。
線はややぼやけていますが、私にとっての経験則は、ビジネスロジックが機能するデータは本文にある必要があり、メタデータはヘッダーに含めることができる/すべきです。
別の見方をすると、特定の種類のリクエストでのみ表示されるデータは本文に含め、アプリケーション全体で一貫して処理されるデータはヘッダーに含める必要があります。
さらに別の視点は、次のとおりです。データの一部がグローバルに処理されることを想像できますか。アプリケーションではなくルーター/ファイアウォールによって？はいの場合、それはおそらく本文ではなくヘッダーに入るはずです。
これらのルールを適用するいくつかの例は次のとおりです。
- ほとんどの場合、アプリケーションのすべての場所で同じように処理されるため、セキュリティ資格情報はヘッダーに入ります。実装レベルでは、実際のエンドポイントがフィルターを通過した場合に、要求を処理する実際のエンドポイントに関係なく、有効な資格情報なしで要求を拒否する要求フィルターがおそらく存在します。
- 一方、管理者がシステムにユーザーを追加できるエンドポイントがある場合、作成されるユーザーのログインはリクエスト本文に含まれている必要があります。次の理由によります。a）アプリケーションのビジネスロジックによって処理されるb）この特定のエンドポイントには表示されますが、他のエンドポイントには表示されません。
- キャッシングを制御するオプションは、ヘッダーにうまく収まる場合があります（キャッシングがアプリケーションのビジネスロジックのコアパーツでない限り）。
一意のデバイスIDに関する質問に戻ります。それがどこでも一貫した方法で使用されている場合。ロギングの場合のみ、ヘッダーに入れることができます。ただし、エンドポイントに応じてさまざまな方法でリクエストをフィルタリングするために使用する場合は、本文に含めることをお勧めします。もちろん、両方のユースケースがある場合は、APIユーザーに同じデータを2か所に配置するよう強制するのではなく、単一の方法で渡す（おそらくヘッダー）ほうがよいため、どちらかを許可するというジレンマが生じる一貫性のない入力またはある種の検証の実装。
クライアント要求の内容。同じサーバーへの複数のリクエストで変更されないものはHEADERの一部になります。資格情報、リクエストごとに頻繁に変更されるものはBODYの一部になります。
OR
メッセージ/本文コンテンツのプロパティはヘッダーに入ります。例）エンコードタイプ、コンテンツ長、コンテンツタイプ。
そして
あなたの場合、フィルターのようなパラメーターは、URLのクエリ/リクエストパラメーターとして追加する必要があります。
/mobiles?type=MOTO&colour=black
RESTfulサービスでは、URL自体がオブジェクトを参照します
/conferences/{conference_id}->特定の会議を参照