REST APIで「まだ準備ができていません。後でもう一度やり直してください」のHTTPステータスコードを選択するには [閉まっている]

私はhttp://server/thingyapi/thingyblob/1234、ダウンロードするもの1234に関連付けられたファイル（別名「blob」）を返すRESTful APIを開発しています。ただし、サーバーにファイルが存在しないときに要求が行われた可能性がありますが、後で確実に使用できるようになります。サーバーには、すべてのもののすべてのblobを生成するバッチプロセスがあります。Thingy 1234はすでに存在し、Blob以外のそのデータはすでに利用可能です。サーバーは、まだ1234のblobを生成する必要がありません。

404を返したくありません。それは存在しないもののためのものです。これは存在するものですが、そのBLOBはまだ生成されていません。ちょっと「処理中」のYouTube動画が好きです。リダイレクトコードも適切だとは思いません。試す「他の」URLはありません。

このような場合に返される正しいHTTPステータスコードは何ですか？

お勧めし202 - Acceptedます。ドキュメントから：

リクエストは処理のために受け入れられましたが、処理は完了していません。[...]その目的は、サーバーが他のプロセス（おそらく、1日1回だけ実行されるバッチ指向のプロセス）の要求を受け入れることを可能にすることです。

このような「問題」はサーバー側にあります。クライアントは整形式の要求を行いましたが、サーバーはそれを満足できません。したがって、「サーバーエラー」、5xxステータスコードを使用する傾向があります。

Quoth RFC 7231（現在のHTTP標準、強調が追加されています）：

ステータスコードの5xx（サーバーエラー）クラスは、サーバーがエラーを検出したか、要求されたメソッドを実行できないことをサーバーが認識していることを示します。HEADリクエストに応答する場合を除いて、サーバーは、エラー状況の説明と、それが一時的な状態か永続的な状態かを含む表現を送信する必要があります（SHOULD）。

注意

• 「エラーが発生したか、リクエストを実行できません」：「サーバーエラー」というタイトルにもかかわらず、サーバーエラーだけではありません。
• 「一時的または永続的」：これらのコードは、あなたのような一時的に利用できないリソースに適しています。

利用可能なコードのうち、503、「Service Unavailable」が最適でした。

503（Service Unavailable）ステータスコードは、一時的な過負荷または定期メンテナンスのために、サーバーが現在リクエストを処理できないことを示しています。サーバーは、リクエストを再試行する前にクライアントが待機する適切な時間を提案するために、Retry-Afterヘッダーフィールドを送信する場合があります。

注意：

• 「少し遅れて緩和される可能性が高い」：ケースに当てはまります。
• 「一時的な過負荷」：あなたのケースでは、はっきりとは当てはまりません。ただし、サーバーがはるかに高速である場合、クライアントが要求を行ったときにバッチ処理が既に行われているため、それは一種の「過負荷」です。つまり、クライアントはサーバーが実行できるよりも速くリソースを要求しています。それらは利用可能です。
• 再試行はサービスに適しているため、返信にはRetry-After値を含める必要があります。バッチプロセスの次の実行の推定完了時間、またはバッチプロセスの実行間隔を値として提供できます。

独自の5xxステータスコード（たとえば、591）を定義すると、は許可されますが、セマンティクスが正しくなくなります。

クライアントは、最初の桁で示されるように、ステータスコードのクラスを理解し、認識されないステータスコードをそのクラスのx00ステータスコードと同等のものとして扱う必要があります。

クライアントは、自分のステータスコードを500「内部サーバーエラー」として扱いますが、これは正しくありません。

423-Lockedはこの目的に使用できると思います：

423（ロック済み）ステータスコードは、メソッドのソースまたは宛先リソースがロックされていることを意味します。この応答には、「lock-token-submitted」や「no-conflicting-lock」などの適切な前提条件または事後条件コードを含める必要があります（SHOULD）。

404を返したくありません。それは存在しないもののためのものです。

URLはThingのリクエストに対応していません。

http://server/thingyapi/thingyblob/1234

クライアントは、存在しないthingyblobを要求しています。それが存在する場合、あなたは彼らにそれを与えるでしょう。

404。

別のオプション：503 - Service Unavailable。

リソースの準備ができていないので、リソースがいつ（およそ）使用可能になるのか、およびクライアントがいつ要求を再試行するのかがわかるでしょう。これは、Retry-Afterヘッダーを利用したい場合があることを意味します。このヘッダーは503（Service Unavailable）で有効です。これは、メンテナンスのためにサイト全体がダウンしていることを意味し、3xx（リダイレクト）応答があります。

私の意見では、Retry-Afterヘッダー付きの302（Found）が最良のオプションですが、応答ヘッダーのLocationフィールドが要求URLと等しいかどうかはわかりません。とにかく、それは循環リダイレクトです。

409紛争

複数の更新の場合の編集の競合など、要求の競合のために要求を処理できなかったことを示します。[出典ウィキペディア。]

これは適切な場合があります。

データを返すことで要求を満たすことができない場合は、成功しません。202は、サーバーが要求をキューに入れ、後で要求を実行することを示唆していると思います。しかし、あなたの場合、リクエストは現在データ用であり、失敗しています。後で再試行すると、別の要求になります。

競合していると思います。データが必要ですが、編集中または更新中です。これは、Thingy1234が既に存在し、以前は正常にダウンロードされていたが、現在編集中である場合、編集が行われている間は利用できなかった場合にも当てはまります。

501-実装されていません

それがどのように聞こえるかがまさに好きです。まだ実装されていないが、将来の可用性を意味する機能。

5xxエラーの概要へのリンクは次のとおりです。