外部データソースからの「利用可能なデータなし」のHTTPステータスコード
シナリオ：
POSTリクエストは、外部データソースからデータを取得するオーダーを処理するために送信されます。
次の3つの結果が考えられます。
- データソースがリクエストのデータを返しました
- 要求に使用できるデータがありませんでした（これはエラーと見なされます）
- データソースにアクセスできませんでした（メンテナンスのためにダウンしている可能性があります）
1の明らかな応答は200: OKまたは201: Created（このリクエストからエンティティが作成されます）。
2および3に適切なステータスコードは何ですか？
検討したステータスコード：
503: Service Unavailableデータソースがダウンしているとき500: Internal Server Errorデータソースがダウンしているとき502: Bad Gateway「利用可能なデータがない」場合404: Not Found「利用可能なデータがない」場合403: Forbidden「利用可能なデータがない」場合412: Precondition Failed「利用可能なデータがない」場合
2）これを振り返ってみると、返される構造に応じて、おそらく204 No Contentか200で、レコードまたはリソースが見つからないことを示す本文を持つ必要があることに同意します。 404は、通常、リソースURIが存在しない場合、またはRESTfulサービスの場合にURIのリソースが見つからない場合に使用されます。
3）503サービス利用不可
サーバーは、サーバーの一時的な過負荷またはメンテナンスのため、現在リクエストを処理できません。これは、これが一時的な状態であり、しばらくすると緩和されるという意味です。既知の場合、遅延の長さはRetry-Afterヘッダーで示される場合があります。 Retry-Afterが指定されていない場合、クライアントは500応答の場合と同様に応答を処理する必要があります。
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
3）503に同意します
2）率直に言って、ケース2で204を使用することについて良い議論ができると思います。ヘッダーにmetainfoを含めて、具体的に「間違った」ことを示すことができます。 APIレベルでこのケースを「エラー」とみなす度合いに大きく依存します。
API自体が意図したとおりに機能しており、認証され許可されたユーザーによる有効なエンドポイントへのリクエストであり、サーバーが誤動作しない場合、400または500シリーズのエラーはほとんど適用されないようです。
たとえば、404は通常、呼び出したURIが存在しない場合、存在する場合、そのコードを使用することは少なくとも私見を誤解させることを意味します
**10.2.5 204 No Content**サーバーは要求を実行しましたが、エンティティ本体を返す必要はなく、更新されたメタ情報を返したい場合があります。応答には、エンティティヘッダーの形式で新規または更新されたメタ情報が含まれている場合があります。これは、存在する場合、要求されたバリアントに関連付けられる必要があります。
クライアントがユーザーエージェントである場合、リクエストの送信を引き起こしたドキュメントビューからドキュメントビューを変更すべきではありません。この応答は主に、ユーザーエージェントのアクティブなドキュメントビューを変更せずにアクションの入力を許可することを目的としていますが、新規または更新されたメタ情報は、ユーザーエージェントのアクティブビューに現在あるドキュメントに適用される必要があります。
204応答にはメッセージ本文を含めてはならない（MUST NOT）ため、ヘッダーフィールドの後の最初の空行で常に終了します。
HTTP 404-「データが見つかりません」などの独自のエラーメッセージ。
Twitterは404を使用します。参照： https://developer.Twitter.com/en/docs/basics/response-codes.html