ステータスコード415：Unsupported Media Typeとは？フォーマット不一致の原因と解決策

新しいAPIと連携しています。適切なデータがすべて含まれたJSONリクエストを慎重に作成し、送信しました。しかし、期待していた成功応答の代わりに、イライラするエラーが返ってきました: 415 Unsupported Media Type。認証、エンドポイントURL、データペイロードを再確認しましたが、すべてが正しいように見えます。では、何が問題だったのでしょうか？

問題は、あなたが何を送ったかではなく、サーバーにどのように送ったかを伝えた方法にある可能性が高いです。この一般的でありながらしばしば混乱を招くステータスコードは、データ形式におけるコミュニケーションの不具合に関するものです。

415エラーは、サーバーが「データを送ろうとしているのは理解できるが、この言語は話せない。実際に処理できる別の形式で送ってくれると思っていた」と伝えているのです。

APIを構築しているか利用しているかにかかわらず、APIを扱う開発者にとって、415ステータスコードを理解することは、スムーズな統合とイライラするデバッグセッションを避けるために不可欠です。

この詳細なガイドでは、415 Unsupported Media Typeステータスコードが何を意味するのか、なぜ発生するのか、典型的なシナリオ、そしてそれを修正または回避するための実践的な方法を探ります。API統合に取り組む開発者であろうと、ウェブ通信の仕組みに興味がある人であろうと、この記事は415エラーをマスターするのに役立つでしょう。

💡

APIリクエストが誤ったメディアタイプのために失敗しないようにしたいなら、今すぐApidogをお試しください。無料でダウンロードでき、使い方も簡単で、開発者がコンテンツタイプの不一致を即座に検出するのに役立ちます。Apidogを使えば、さまざまなヘッダーをシミュレートしたり、自動テストを実行したり、チームと共同作業したり、すべてを1か所で行うことができます。

button

それでは、HTTP 415に関する混乱をきっぱりと解消しましょう。

問題：サーバーの言語を話す

フランス語しか読めない人に手紙を送る状況を想像してみてください。あなたは最も雄弁で完璧に構成された英語の手紙を書いたとしても、受取人が英語を理解できなければ、あなたのメッセージは無意味になります。415エラーは、このシナリオのデジタル版です。

ウェブサーバーは、特定のデータ形式を理解するように構築されていることがよくあります。受信データがどの「言語」で書かれているかを知る必要があり、それによって適切に解析および処理できます。Content-Typeヘッダーは、クライアントがサーバーにデータの形式を伝える方法です。

HTTP 415 Unsupported Media Type は実際に何を意味するのか？

415 Unsupported Media Typeステータスコードは、サーバーがリクエストを理解しているものの、ペイロード形式（メディアタイプ）が、リクエストされたリソースに対してサーバーがサポートしていない形式であるため、受け入れを拒否していることを示します。

簡単に言えば、あなたのクライアント（Postman、Apidog、またはブラウザなど）が、サーバーが理解できない、または処理するように設定されていない形式でデータを送信しているということです。

サーバーは基本的にこう言っています。「データは受け取ったが、この特定のエンドポイントでは理解できない、またはサポートしていない形式であるため、処理できない。」

典型的な415応答は次のようになります。

HTTP/1.1 415 Unsupported Media TypeContent-Type: application/json
{
  "error": "Unsupported Media Type",
  "message": "The request payload format is not supported.",
  "supported_types": ["application/json", "application/xml"]
}

これは、「おい！リクエストは受け取ったが、このコンテンツタイプは処理できない」と伝えています。

これは最も一般的に、送信されるデータの形式（JSON、XML、マルチパートフォームデータなど）を指定するHTTPリクエストのContent-Typeヘッダーの値に関連しています。一部のサーバーは、サポートしている形式に関するより役立つ情報を提供するかもしれませんが、他のサーバーはより一般的なエラーメッセージを返すかもしれません。

深掘り：技術的な定義（好奇心旺盛な方向け）

HTTP/1.1仕様 (RFC 7231) のセクション6.5.13によると、415ステータスコードは次のように定義されています。

「415 (Unsupported Media Type) ステータスコードは、オリジンサーバーがリクエストの処理を拒否していることを示します。これは、ペイロードがターゲットリソース上のこのメソッドでサポートされていない形式であるためです。」

ここでの重要なポイント：

問題はデータ自体ではなく、メディアタイプにあります。
サーバーはあなたが何を送信しようとしているかを知っていますが、それを処理できないだけです。

問題の核心：Content-Type ヘッダー

Content-Typeヘッダーは、415エラーを受け取るか、成功応答を受け取るかを決定する重要な情報です。このヘッダーは、リクエストボディで送信しているデータの種類をサーバーに伝えます。

遭遇する可能性のある最も一般的なコンテンツタイプは次のとおりです。

一般的なContent-Typeの値：

JSON APIの場合：

application/json - ほとんどの最新REST APIの標準
application/json; charset=utf-8 - 明示的な文字エンコーディングを持つJSON

フォームデータの場合：

application/x-www-form-urlencoded - 従来のHTMLフォーム送信形式
multipart/form-data - ファイルアップロードおよびファイルを含むフォームに使用

XMLの場合：

application/xml - 標準XML形式
text/xml - 代替XML形式

プレーンテキストの場合：

text/plain - シンプルなテキストコンテンツ
text/html - HTMLコンテンツ

415エラーの発生方法：ステップバイステップの内訳

415エラーが発生したときに何が起こるのか、正確に見ていきましょう。

ステップ1：クライアントがリクエストを送信する

クライアントアプリケーションは、サーバーAPIエンドポイントにリクエストを送信します。例えば、新しいユーザーを作成しようとしているとします。

POST /api/users HTTP/1.1Host: api.example.comContent-Type: application/xmlContent-Length: 125
<user><name>John Doe</name><email>john@example.com</email></user>

ステップ2：サーバーがContent-Typeを確認する

サーバーはリクエストを受信し、Content-Typeヘッダーを調べます。application/xmlを確認し、/api/usersエンドポイントの設定をチェックします。

ステップ3：サーバーが問題を認識する

サーバーの/api/usersエンドポイントは、application/jsonのみを受け入れるように設定されています。このエンドポイントにはXMLパーサーが設定されておらず、受信データをどのように処理すればよいか分かりません。

ステップ4：415応答

不正な形式のデータ（エラーやセキュリティ問題につながる可能性がある）を処理しようとする代わりに、サーバーは415 Unsupported Media Typeステータスコードで応答します。

ステップ5：クライアントがエラーを受信する

クライアントアプリケーションは415応答を受信し、通常はContent-Typeヘッダーを修正してリクエストを再送信することで、適切に処理する必要があります。

415に遭遇する可能性のある一般的なシナリオ

1. APIでのファイルアップロード

multipart/form-dataの代わりにapplication/jsonを使用して画像をアップロードしようとすると、サーバーはファイルの内容を理解できません。

2. 厳格な検証を伴うカスタムAPI

厳格なスキーマ検証を持つAPIは、そのルールに一致しないリクエストをすべて拒否します。

3. 古いSDKを使用しているモバイルアプリ

古いSDKは、現代のAPIがもはやサポートしていない古いヘッダーを持つリクエストを送信することがあります。

4. クロスオリジンリクエスト（CORSの問題）

特定のCORS設定は、受け入れられるコンテンツタイプを制限することがあり、間接的に415応答を引き起こす可能性があります。

Content-Type ヘッダーの役割

HTTPリクエストのContent-Typeヘッダーは、クライアントがどのような種類のデータを送信しているかをサーバーに伝えます。

例えば：

JSONペイロードの場合はapplication/json。
XMLデータの場合はtext/xml。
ファイルアップロードの場合はmultipart/form-data。

このヘッダーが欠落しているか、サーバーが処理できない内容を伝えている場合、415応答が表示される可能性が高いです。

415エラーを引き起こす現実世界のシナリオ

シナリオ1：Content-Typeヘッダーの欠落

POST /api/users HTTP/1.1Host: api.example.com

{"name": "John Doe", "email": "john@example.com"}

多くのサーバーは、データをどのように解釈すべきかを伝えるContent-Typeヘッダーがないため、これを拒否するでしょう。

シナリオ2：データに対する誤ったContent-Type

POST /api/users HTTP/1.1Host: api.example.comContent-Type: application/x-www-form-urlencoded

{"name": "John Doe", "email": "john@example.com"}

ヘッダーはフォームデータであると示していますが、ボディはJSONです。この不一致がサーバーを混乱させます。

シナリオ3：サーバーが形式をサポートしていない

POST /api/users HTTP/1.1Host: api.example.comContent-Type: application/xml
<user><name>John</name></user>

XMLが適切に形成されていても、サーバーはこのエンドポイントでJSONのみをサポートしている可能性があります。

ApidogでContent-Typeの処理をテストする

これらのエラーに対処する際に、Apidogがどのようにあなたの生活を楽にするかについて話しましょう。異なるコンテンツタイプをテストし、APIがそれらを正しく処理することを確認する点でApidogは優れています。複雑なコードを書くことなく、これらのシナリオを驚くほど簡単にテストできます。

Apidogを使用すると、次のことができます。

Content-Typeヘッダーを簡単に設定： Apidogの直感的なインターフェースを使用して、一般的なコンテンツタイプから選択したり、カスタムのものを指定したりできます。
複数の形式をテスト： 同じエンドポイントを異なるコンテンツタイプ（JSON、XML、フォームデータ）で迅速にテストし、サーバーがどのように応答するかを確認できます。
エラー応答を検証： サポートされていない形式を受信したときに、APIが役立つエラーメッセージとともに適切な415応答を返すことを確認します。
エッジケースをテスト： 不正な形式のコンテンツタイプ、欠落したヘッダー、または不一致のデータを試して、APIがそれらを適切に処理することを確認します。
Content-Typeテストを自動化： APIがサポートされている形式を正しく受け入れ、サポートされていない形式を適切に拒否することを自動的に検証するテストスイートを作成します。

button

例えば、ApidogでPOSTリクエストを設定すると、リクエストボディのタイプ（JSON、XML、フォームデータなど）に基づいて、正しいContent-Typeが自動的に適用されます。

これにより、予期せぬ事態が減り、415エラーがテストセッションを台無しにすることがなくなります。このプロアクティブなテストは、デバッグ時間を大幅に節約し、APIが予測どおりに動作することを保証します。

415とその他の4xxエラー：違いを知る

415を他のクライアントエラーと区別することが重要です。

400 Bad Request: コンテンツタイプに関係なく、リクエストの形式が不正であるか、構文エラーがあります。
415 Unsupported Media Type: リクエストは適切に形成されていますが、サーバーがこのエンドポイントでサポートしていない形式です。
406 Not Acceptable: 415の逆で、クライアントがサーバーが送信したい応答形式を受け入れられません。

415エラーを処理するためのベストプラクティス

APIコンシューマー（クライアント開発者）向け：

リクエストボディの形式と一致する正しいContent-Typeヘッダーを常に設定してください。
各エンドポイントでサポートされているメディアタイプを確認するために、APIドキュメントをチェックしてください。
コード内で415エラーを適切に処理してください。サーバーが送信する任意の形式を受け入れると仮定しないでください。
可能であれば、データをサポートされている形式に変換するなど、フォールバック動作を提供してください。

APIプロバイダー（サーバー開発者）向け：

APIドキュメントでサポートされているメディアタイプを明示してください。
サポートしているメディアタイプを示す役立つエラーメッセージを返してください。
APIにとって意味がある場合（例：JSONとXMLの両方など）、複数の形式のサポートを検討してください。
適切なHTTPステータスコードを使用してください。415を意味する場合に400を使用しないでください。

適切に設計された415応答の例：

HTTP/1.1 415 Unsupported Media TypeContent-Type: application/json
{
  "error": "unsupported_media_type",
  "message": "This endpoint only accepts application/json payloads.",
  "supported_types": ["application/json"],
  "documentation": "<https://api.example.com/docs/content-types>"
}

415を引き起こす一般的なContent-Typeの間違い

開発者が陥りがちな落とし穴をいくつか紹介します。

間違い	説明	例
誤ったヘッダー名の使用	タイプミスまたは大文字小文字の問題	`contenttype`の代わりに`Content-Type`
JSONの代わりにフォームデータを送信	サーバーはJSONのみを期待している	`application/x-www-form-urlencoded`
charsetの忘れ	エンコーディング情報の欠落	`application/json; charset=utf-8`
空のボディを送信	必須ペイロードの欠落	データなしの`POST /api`
サポートされていないファイルタイプの使用	誤ったアップロード形式	`.png`の代わりに`.exe`をアップロード

これらは些細なことのように見えますが、大きなリクエスト失敗の原因となることがあります。

415エラーの一般的な修正方法

415エラーに遭遇した場合、最も一般的な解決策は次のとおりです。

不足しているContent-Typeヘッダーを追加する：

POST /api/users HTTP/1.1Content-Type: application/json

Content-Typeヘッダーを修正する：

# Before (wrong):
Content-Type: text/plain
# After (correct):
Content-Type: application/json

データをサポートされている形式に変換する：

サーバーがJSONのみを受け入れる場合、XMLやフォームデータではなく、適切なJSONを送信していることを確認してください。

タイプミスを確認する：

# Wrong:
Content-Type: application/jason

# Correct:
Content-Type: application/json

高度な考慮事項

コンテンツネゴシエーション

一部の高度なAPIはコンテンツネゴシエーションをサポートしており、クライアントはAcceptヘッダーを使用して受け入れ可能な形式を指定できます。

GET /api/users/123 HTTP/1.1Accept: application/json, application/xml;q=0.9

これはサーバーに「JSONを好むが、必要であればXMLも受け入れられる」と伝えます。

Charsetパラメーター

テキストベースの形式の場合、文字エンコーディングを指定する必要があるかもしれません。

Content-Type: application/json; charset=utf-8

結論：明確なコミュニケーションの重要性

HTTP 415 Unsupported Media Typeステータスコードは、ウェブ通信の根本的な側面を浮き彫りにします。それは、両当事者がデータを交換するために使用する「言語」について合意する必要があるということです。正しいデータを送信するだけでは不十分であり、正しい形式で送信し、その形式が何であるかを適切に宣言する必要があります。

HTTP 415 Unsupported Media Typeは、サーバーが期待される互換性のあるデータ形式のみを処理することを保証する上で重要な部分です。Content-Typeヘッダーを正しく処理し、API仕様に従い、Apidogのようなツールでテストすることで、これらのエラーを劇的に減らすことができます。

415エラーを理解し適切に処理することで、より効果的なAPIコンシューマーとなり、より優れたAPIデザイナーになることができます。コンテンツタイプに注意を払い、クライアントとサーバー間の明確なコミュニケーションを提供することで、これらのイライラするエラーを回避し、より堅牢な統合を構築できます。APIはクライアントとサーバー間の明確なコミュニケーションによって成り立っていることを忘れないでください。もし両者が同じ「言語」（この場合はメディアタイプ）を話せば、すべてがスムーズに進みます。

したがって、次に415エラーに遭遇したときは、それが複雑なサーバー障害ではなく、通常は簡単に修正できる単純なコミュニケーションの問題であることを思い出してください。APIを構築またはテストする際には、Apidogのようなツールを使用することで、コンテンツタイプが常に正しいことを確認し、これらのエラーが発生する前に防ぐことができます。

button