REST APIで「準備ができていません。後で再試行してください」のHTTPステータスコードを選択するにはどうすればよいですか？
http://server/thingyapi/thingyblob/1234が、ダウンロードするためにthingy＃1234に関連付けられたファイル（別名「blob」）を返すRESTful APIを開発しています。ただし、ファイルがサーバーに存在しない時点でリクエストが行われた可能性がありますが、最も確実に（）後で利用可能になります。サーバーには、すべてのもののすべてのBLOBを生成するバッチプロセスがあります。 Thingy 1234はすでに存在しており、ブロブ以外のデータはすでに利用可能です。サーバーはまだ1234のblobを生成する必要はありません。
404を返したくありません。それは存在しないもののためのものです。これは存在するものですが、そのblobはまだ生成されていません。 「処理中」のYouTubeビデオが好きです。リダイレクトコードも適切だとは思いません。試す「他の」URLはありません。
そのような場合に返す正しいHTTPステータスコードは何ですか？
202 - Acceptedをお勧めします。 ドキュメント から：
要求は処理のために受け入れられましたが、処理は完了していません。 [...]その目的は、サーバーが他のプロセス（おそらく1日に1回だけ実行されるバッチ指向のプロセス）の要求を受け入れることです。
このような「問題」はサーバー側にあります。クライアントは整形式のリクエストを行いましたが、サーバーはそれを満足できません。だから私は「サーバーエラー」、5xxステータスコードに傾いています。
Quoth RFC 7231 （現在のHTTP標準、強調が追加されました）：
ステータスコードの5xx（サーバーエラー）クラスは、サーバーがエラーを認識しているか、要求されたメソッドを実行できないことを示しています。 HEADリクエストに応答する場合を除き、サーバーは、エラー状況の説明と、それがtemporaryまたは永続的な状態。
注意
- 「エラーorはリクエストを実行できません」：タイトルが「サーバーエラー」であるにもかかわらず、サーバーエラーだけではありません。
- 「temporaryor permanent」：これらのコードは、あなたのような一時的に利用できないリソースに適しています。
利用可能なコードのうち、 503、 "Service Unavailable" が最適でした。
503（Service Unavailable）ステータスコードは、一時的な過負荷または定期的なメンテナンスが原因でサーバーが現在リクエストを処理できないことを示しています。サーバーは、Retry-Afterヘッダーフィールドを送信して、クライアントがリクエストを再試行するまで待機する適切な時間を提案することができます。
注意：
- 「少し遅れて緩和される可能性が高い」：あなたの場合はtrue。
- 「一時的な過負荷」：あなたのケースでは、ペダンに当てはまりません。しかし、あなたのサーバーがはるかに高速であれば、クライアントが要求を行ったときにバッチ処理が既に行われていると主張することができるので、is一種の「過負荷」：クライアントはサーバーが使用可能にするよりも高速なリソース。
- 再試行はサービスに適しているため、返信には
Retry-After値を含める必要があります。値として、バッチプロセスの次の実行の推定完了時間、またはバッチプロセスの実行間隔を指定できます。
独自の5xxステータスコード（591など）を定義すると、 permitted になりますが、セマンティクスが間違っています。
クライアントは、最初の数字で示されているように、ステータスコードのクラスを理解し、認識されていないステータスコードをそのクラスのx00ステータスコードに相当するものとして扱わなければなりません
クライアントは、独自のステータスコードを 500、 "Internal Server Error" として扱いますが、これは正しくありません。
423-Locked はこの目的に使用できると思います：
423（ロック）ステータスコードは、メソッドのソースまたは宛先リソースがロックされていることを意味します。この応答には、 'lock-token-submitted'や 'no-conflicting-lock'などの適切な前提条件または事後条件コードを含める必要があります。
別のオプション：503 - Service Unavailable。
404を返したくありません。それは存在しないもののためのものです。
このURLは、何かのリクエストに対応していません。
http://server/thingyapi/thingyblob/1234
クライアントは、存在しないthingyblobを要求しています。それが存在する場合、あなたは彼らにそれを与えるでしょう。
404。
リソースの準備ができていないため、いつ（およそ）リソースが利用可能になり、クライアントがいつリクエストを再試行できるかを知っているでしょう。これは、 Retry-After header を利用したい場合があることを意味します。このヘッダーは、503（Service Unavailable）で有効です。これは、メンテナンスのためにサイト全体がダウンしていることを意味し、3xx（Redirection）応答です。
私の意見では、Retry-Afterヘッダーを使用した302（Found）が最適なオプションですが、応答ヘッダーのLocationフィールドをrequest urlと等しくできるかどうかはわかりません。とにかく、循環リダイレクトです。
409紛争
複数の更新の場合の編集の競合など、リクエストの競合が原因でリクエストを処理できなかったことを示します。 [ソースウィキペディア。]
これが適切な場合があります。
データを返してリクエストを処理できない場合は、成功しません。 202は、サーバーがリクエストをキューに入れており、後でリクエストを処理することを示唆していると思います。しかし、あなたの場合、リクエストは現在データ用であり、失敗しています。後で再試行する場合は、別のリクエストです。
競合が発生していると思います。データが必要ですが、編集/更新中です。これは、Thingy1234がすでに存在し、以前に正常にダウンロードされていたが、現在編集中だったが、編集中は利用できなかった場合にも当てはまります。