2.2. エラー処理 (Error Handling)

2.2. エラー処理 (Error Handling)

PATCH リクエストが失敗する可能性のあるいくつかの既知の条件があります.

不正な形式のパッチドキュメント (Malformed patch document): サーバーがクライアントから提供されたパッチドキュメントが適切にフォーマットされていないと判断した場合、400 (Bad Request) レスポンスを返すべきです (SHOULD). 不正なフォーマットの定義は、選択されたパッチドキュメントによって異なります.

サポートされていないパッチドキュメント (Unsupported patch document): クライアントが Request-URI によって識別されるリソースに対してサーバーがサポートしていないパッチドキュメントフォーマットを送信した場合、415 (Unsupported Media Type) レスポンスを使用して指定できます. そのようなレスポンスには、セクション 3.1 で説明されているように、サーバーがサポートするパッチドキュメントメディアタイプをクライアントに通知するための Accept-Patch レスポンスヘッダーを含めるべきです (SHOULD).

処理不可能なリクエスト (Unprocessable request): サーバーがパッチドキュメントを理解し、パッチドキュメントの構文が有効であると思われるが、サーバーがリクエストを処理できない場合、422 (Unprocessable Entity) レスポンス ([RFC4918], セクション 11.2) を使用して指定できます. これには、リソースを無効にする方法でリソースを変更しようとする試みが含まれる場合があります. たとえば、整形式の XML ドキュメントへの変更により、整形式でなくなる場合などです. 上記のように、"競合状態 (Conflicting State)" などのより具体的なエラーもある可能性があります. このような場合、サーバーはレスポンスボディにエラー情報を含めて (MAY)、ユーザーがパッチリクエストの何が問題だったかを判断できるようにします.

リソースが見つかりません (Resource not found): クライアントがパッチを適用しようとしているリソースが存在せず、サーバーが PATCH での新しいリソースの作成をサポートしていない場合、サーバーは 404 (Not Found) ステータスコードを返します.

競合状態 (Conflicting state): リクエストが適切にフォーマットされており、サーバーがパッチドキュメントで使用されているメディアタイプをサポートしているが、リソースの状態がパッチと競合しているため、またはパッチが競合を作成するため (たとえば、競合するフィールドを追加しようとするパッチ、または失敗した条件付きリクエスト)、サーバーがパッチを適用できない場合、サーバーは 409 (Conflict) ステータスコードを返します. サーバーは、クライアントが競合の原因を認識できるように、レスポンスボディに十分な情報を含めるべきです (SHOULD).

競合する変更 (Conflicting modification): リクエストが適切にフォーマットされており、サーバーがメディアタイプをサポートしているが、リソースが予想される状態から変更されているため (たとえば、条件付きリクエストが失敗した、強力な ETag が現在のリソースと一致しない)、パッチをリソースに適用できない場合、サーバーは 412 (Precondition Failed) ステータスコードを返します.

並行変更 (Concurrent modification): 使用されているパッチフォーマットがクライアントが基礎となるベースドキュメント (base document) から作業することを要求する場合、PATCH でリソースを変更する同時リクエストは予測不可能な結果をもたらす可能性があります. したがって、並行更新が競合を引き起こす場合、PATCH リクエストは失敗する可能性があります. このようなすべての並行変更リスクは、複数の関係者が同じリソースに変更を加える相互作用に適用されます. PATCH メソッドは固有のリスクを導入しませんが、このセクションで強調する価値があります.

注意: すべてのレスポンスについて、サーバーはレスポンスボディにエラー情報を含めて、クライアントが何が問題だったか、または次に何をすべきかを判断できるようにすることができます.