メインコンテンツまでスキップ

4.8. Defining Message Content (メッセージコンテンツの定義)

4.8. Defining Message Content (メッセージコンテンツの定義)​

HTTP を使用するアプリケーションは, 通常 1 つ以上のメディアタイプ [RFC6838] を定義することによって, リクエストとレスポンスのコンテンツの形式を指定しなければなりません (MUST)。その場合, [RFC6838] の手順に従ってそれらのメディアタイプを登録すべきです (SHOULD)。

一般的な形式には次のものが含まれます:

  • JSON [JSON]

  • XML [XML]

  • CBOR [RFC8949]

  • Protocol Buffers

  • アプリケーション固有のカスタム形式

コンテンツを指定するとき, アプリケーションは次のことをすべきです (SHOULD):

  • 可能な限り既存の, 広く理解されているメディアタイプを使用する (例: JSON コンテンツには application/json)。

  • 必要に応じて新しいメディアタイプを定義し, 適切なツリーを使用する (例: JSON ベースのベンダー固有形式には application/vnd.example.myapp+json)。

  • コンテンツの構造とセマンティクスを明確に指定する。

  • コンテンツネゴシエーションを使用して同じリソースの複数の表現をサポートすることを検討する ([HTTP] セクション 12 を参照)。

  • Content-Type ヘッダーフィールドを使用して, 送信されているコンテンツのメディアタイプを示す。

  • Accept ヘッダーフィールドを使用して, クライアントが受信する意思があるメディアタイプを示す。

アプリケーションは, クライアントとサーバーがリソースの表現について合意できるようにするために, コンテンツネゴシエーションをサポートすべきです (SHOULD)。これは, リクエストの Accept ヘッダーフィールドとレスポンスの Content-Type ヘッダーフィールドを使用して行われます。

たとえば, クライアントは次のように送信する場合があります:

Accept: application/json, application/xml;q=0.9

これは JSON を好むが, 多少優先度は低いが XML も受け入れることを示します。

サーバーは, 提供できるものとクライアントの優先度に基づいて, 最も適切な表現で応答できます。

に最終更新