HTTPリクエストヘッダーとリクエストボディの違いは何ですか？

私はモバイルクライアント用の一連のWebサービスに取り組んでいます。要件では、すべてのリクエストに含まれ、特定のリクエストに格納され、他のリクエストで結果をフィルタリングするために使用される一意のデバイスIDが必要です。

すべてのリクエストに含まれるので、カスタムHTTPヘッダーに入れることを提案しました。そのため、特定のデータがヘッダーにあるのか、他のデータと一緒にあるのかを判断するためにどの基準を使用するのか疑問に思い始めましたリクエスト本文。

そのような基準はありますか？

情報が重要な場合は、それを身体に入れる必要があります。

どうして？

1. プロキシサーバーはヘッダーを変更できます。多くは、知らないヘッダーを取り除くように構成されています。ただし、これは暗号化されていないHTTPを使用する場合にのみ適用されます。HTTPSを使用する場合、プロキシはヘッダーが暗号化されているため、ヘッダーを変更できません。
2. Webサービスを使用する場合、通常は他のデバイス、サービス、ツールとの相互運用性のために使用します。Webサービスで動作するほとんどのAPIおよびツールは、リクエストを簡単に変更できますが、多くの場合、カスタムヘッダーを追加することが困難または不可能になります。もちろん、これは相互運用性が懸念される場合にのみ適用されます。しかし、気にしない場合は、生のTCPで独自のプロトコルを構築するのではなく、そもそもWebサービスを使用している理由を自問する必要があります。

行は多少ぼやけていますが、私にとっての経験則は次のとおりです。ビジネスロジックが機能するデータは本文にあるべきであり、メタデータはヘッダーに入れることができる/すべきです。

別の見方をすると、特定の種類のリクエストでのみ表示されるデータは本文にあり、アプリケーション全体で一貫して処理されるデータはヘッダーに入力する必要があります。

さらに別の観点は次のとおりです。たとえば、アプリケーションではなくルーター/ファイアウォールによって、データの一部がグローバルに処理されると想像できますか？はいの場合、おそらく本文ではなくヘッダーに入れる必要があります。

これらのルールを適用するいくつかの例は次のとおりです。

• ほとんどの場合、アプリケーションのすべての場所で同じように処理されるため、セキュリティ資格情報はヘッダーに入ります。実装レベルでは、実際のエンドポイントがフィルターを通過した場合に処理する実際のエンドポイントに関係なく、有効な資格情報のない要求を拒否する要求フィルターが存在する可能性があります。
• 一方、管理者がシステムにユーザーを追加できるエンドポイントがある場合、作成されるユーザーのログインは、次の理由でリクエスト本文に含まれている必要があります。a）アプリケーションのビジネスロジックによって処理される、b）この特定のエンドポイントには表示されますが、他のエンドポイントには表示されません。
• キャッシングを制御するオプションは、ヘッダーにうまく適合する可能性があります（キャッシングがアプリケーションのビジネスロジックの中核部分でない限り）。

一意のデバイスIDについての質問に戻ります。それがどこでも一貫した方法で使用されている場合（たとえば、ロギングのみ）、ヘッダーに配置できます。ただし、エンドポイントに応じてさまざまな方法で要求をフィルタリングするために使用する場合は、本文に配置することをお勧めします。もちろん、両方のユースケースがある場合は、APIユーザーに同じデータを2か所に配置させるのではなく、ただ1つの方法（おそらくヘッダー）を渡すようにして、どちらかを許可するというジレンマを与えることをお勧めします一貫性のない入力または何らかの検証の実装。

クライアント要求の内容。同じサーバーへの複数のリクエストで変更されないものはHEADERの一部になります。たとえば、資格情報、リクエストごとに頻繁に変更されるその他はBODYの一部になります。

または

メッセージ/本文コンテンツのプロパティはヘッダーに入ります。例）エンコードタイプ、コンテンツ長、コンテンツタイプ。

そして

あなたの場合、フィルタパラメータのようなものは、URLにクエリ/リクエストパラメータとして追加する必要があります。

/mobiles?type=MOTO&colour=black

安らかなサービスでは、URL自体がオブジェクトを参照します

/conferences/{conference_id} ->特定の会議を指します