プロンプトとスコープ
ある API は POST に対して JSON と CBOR を、PATCH に対して JSON Patch を受け入れます。クライアントは、誤った Content-Type、コンテンツエンコーディング、またはパッチドキュメント形式を送信した後に 415 を受信します。サーバー側の分類、レスポンスヘッダー、エラーボディ、クライアントのリカバリ、およびバージョンの進化を設計してください。
これはバックエンド API のコントラクトに関する質問です。メディアタイプと形式は前提条件であり、発生頻度の主張ではありません。
面接官がテストしているポイント
- リクエストの Content-Type および Content-Encoding と、レスポンスの Accept を明確に分離しているか。
- すべてのパースエラーを 415 とするのではなく、415 を限定的かつ適切に使用しているか。
- 互換性を維持しながら、Accept-Patch を使用して PATCH 機能を公開しているか。
- 安全でない自動リプレイを行わずに、エラーが対処可能なものになっているか。
確認すべき明確化のための質問
- 415 の原因はメディアタイプ、コンテンツエンコーディング、メソッドの機能のどれですか？
- クライアントはボディを再エンコードできますか？また、安定したリクエスト ID は存在しますか？
- どのパッチ形式とリソースバージョン条件がサポートされていますか？
- ゲートウェイは Content-Type、エンコーディング、またはエラーボディを書き換える可能性がありますか？
- 古いクライアントを壊すことなく、新しいメディアタイプをどのようにロールアウトしますか？
30秒での回答
「415 は、ターゲットメソッドがリクエスト表現の形式を拒否したことを意味します。サーバーは Content-Type、パラメータ、および Content-Encoding を解析し、メソッドとリソースの機能に基づいてパーサーを選択します。Accept はクライアントが要求するレスポンス形式を記述するものであり、送信されたパッチドキュメントを記述するものではありません。PATCH リソースは Accept-Patch を使用してサポートするドキュメントタイプを通知できます。エラーは安定したコード、受信した値と許可された値、およびリクエスト ID を返します。安全な再エンコードとリプレイ分析の後にのみ再試行します。」
ステップバイステップの設計
1. 3つのヘッダーセマンティクスを分離する
Content-Type はリクエストボディのメディアタイプを表し、Content-Encoding は転送コーディングを表し、Accept はクライアントが受信可能なレスポンス表現を表します。サーバーは PATCH ドキュメントを分類するために Accept を使用したり、解凍エラー、破損、サポートされていないメディアを1つの原因にまとめたりしてはなりません。
2. メソッドとリソースの機能をマッピングする
各メソッドとリソースは、サポートされているメディアタイプとパラメータを宣言します。たとえば、POST は application/json と application/cbor を受け入れ、PATCH は登録された JSON Patch ドキュメントタイプを受け入れます。パースの前にタイプとエンコーディングをチェックし、パース後もスキーマ、認可、およびビジネスバリデーションを実行します。
PATCH /documents/42 HTTP/1.1
Content-Type: application/json-patch+json
Accept: application/json
Content-Length: 1283. 正確な 415 を返す
メディアタイプまたはコンテンツエンコーディングがサポートされていない場合は、安定したエラーコードとともに 415 を返します。構文は正しいが無効なフィールドがある場合はドメインバリデーションエラーを使用し、不正な形式のコンテンツには明確なパースエラーを使用します。Accept レスポンスヘッダーはサーバーが返すことができる表現を記述するものであり、リクエストメディアタイプのリストではありません。
4. PATCH 機能を通知する
RFC 5789 は Accept-Patch を定義しています。リソースは OPTIONS または成功レスポンスで、サポートされているパッチドキュメントのメディアタイプを宣言できます。これにより、クライアントは JSON Patch または別の形式を選択できるようになり、サーバーは引き続きリソースバージョン、パス、および認可をチェックします。通知内容は実際のパーサーセットと一致している必要があります。
5. クライアントリカバリを安全にする
415 の後、クライアントは安定したコードと許可されたタイプを読み取り、ボディを再エンコードするか、互換性のあるエンドポイントを選択します。自動再試行には、再構築可能なボディ、不可逆的な副作用がないこと、および同一の冪等性キーが必要です。成功した可能性のある PATCH を再送信してはならず、415 を一時的な利用不可状態として扱ってはなりません。
6. 変更のロールアウトとオブザーバビリティ
古いタイプとの互換性期間を維持しながら、ゲートウェイ、サーバー、SDK を通じて新しいメディアタイプをカナリアリリースします。メトリクスは、リソース、メソッド、受信したタイプ、エンコーディング、クライアントバージョン、および拒否理由ごとにセグメント化します。リクエスト ID とパーサーバージョンをログに記録し、機密性の高いボディは絶対に記録しません。ゲートウェイがヘッダーを書き換える場合は、エッジヘッダーとアプリケーションヘッダーを比較します。
質の高い模範解答
「私はリクエスト形式とレスポンス形式を分離します。サーバーはメソッドとリソースごとに Content-Type と Content-Encoding をチェックし、サポートされている表現のみをパースした上で、スキーマとビジネスバリデーションを実行します。Accept はレスポンスネゴシエーション用です。PATCH リソースは Accept-Patch でドキュメントタイプを通知しますが、各リクエストでは依然としてバージョンと認可をチェックします。415 ボディは安定したコード、受信値と許可値、およびリクエスト ID を提供します。クライアントは安全に再エンコードした後にのみ再試行します。新しいタイプは互換性マトリクスとメトリクスを通じてロールアウトし、ゲートウェイや古い SDK がセマンティクスを暗黙的に変更しないようにします。」
よくある間違い
- リクエストボディの分類に Accept を使用する → リクエストとレスポンスのネゴシエーションが混同される → Content-Type と Content-Encoding を検証する。
- すべてのパース失敗に対して 415 を返す → クライアントが修復方法を選択できない → メディア、構文、ドメインのエラーを分離する。
- パーサーがないのに Accept-Patch を通知する → 機能コントラクトが虚偽になる → 宣言を実装と照合して検証する。
- 415 の後に同じボディで再試行する → 失敗するか副作用が重複する → エンコーディングを変更し、リプレイの安全性を確認する。
- アプリケーション内でのみタイプをログ出力する → ゲートウェイによる書き換えが見えなくなる → ホップごとにヘッダーとリクエスト ID を比較する。
フォローアップの質問と回答
Content-Type は有効だが Content-Encoding がサポートされていない場合でも、415 は正しいですか？
RFC 9110 では、受け入れられないリクエストのコンテンツコーディングも 415 のスコープに含まれます。エラー内でエンコーディングについて説明し、解凍するかサポートされているエンコーディングを選択した上で、ボディと操作を安全に再試行できるかを判断します。
許可されたタイプのリストだけを返してはいけないのはなぜですか？
単なるリストでは、メソッド、パラメータ、バージョンの制約が省略されてしまいます。安定したコード、受信した値、許可されたスコープ、リクエスト ID、およびドキュメントへのリンクを提供することで、内部構造を公開することなく対処可能な修復を可能にします。
CBOR を安全に追加するにはどうすればよいですか？
まず重要度の低いリソースで有効化し、ゲートウェイのパススルー、パーサーのリソース制限、スキーマの同等性、ログの墨消し（マスキング）を検証します。JSON へのフォールバックを維持し、クライアントバージョンごとに 415、パース失敗、およびビジネス上の成果を比較します。