リソースに対して非同期更新を行う必要があります。202 Accepted が PATCH に対する適切な応答であるかどうかについての決定的な声明はありますか?
公式ドキュメントhereでは、202 について言及されておらず、PATCH によるリソースの変更が同期的に行われると想定しているように見えますが、明確な声明を出すことはありません。
PATCH アクションの適切な回路図は何ですか?
リソースに対して非同期更新を行う必要があります。202 Accepted が PATCH に対する適切な応答であるかどうかについての決定的な声明はありますか?
公式ドキュメントhereでは、202 について言及されておらず、PATCH によるリソースの変更が同期的に行われると想定しているように見えますが、明確な声明を出すことはありません。
PATCH アクションの適切な回路図は何ですか?
なぜ 202 を返すのが悪いのかわかりません。の使用について明示的な言及はありませんが202
、仕様は例でそれを示唆しています。
既存のテキスト ファイルへの成功した PATCH 応答:
HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f"
204 応答コードが使用されるのは、応答にはメッセージ本文が含まれていないためです (200 コードの応答にはメッセージ本文が含まれます)。他の成功コードも使用できることに注意
してください。
202
は成功コードであり、その定義は での使用を禁止していませんPATCH
。
10.2.3 202 承認済み
リクエストは処理のために受け入れられましたが、処理は完了していません。処理が実際に行われるときに許可されない可能性があるため、要求は最終的に処理される場合と処理されない場合があります。このような非同期操作からステータス コードを再送信する機能はありません。
202 応答は、意図的に非コミットです。その目的は、プロセスが完了するまでサーバーへのユーザー エージェントの接続を維持する必要なく、サーバーが他のプロセス (おそらく 1 日に 1 回だけ実行されるバッチ指向のプロセス) の要求を受け入れることを可能にすることです。この応答で返されるエンティティには、要求の現在のステータスの表示と、ステータス モニターへのポインター、またはユーザーが要求がいつ満たされると期待できるかの推定値のいずれかを含める必要があります。
アトミックにパッチを適用し、非同期リクエストによってリソースが半分パッチされた状態のままにならない限り、これで問題ありません。