APIのステータスコードについての話します。
この話は個人的な対応であり、一般的な統一されたものではないので、賛否両論あります。
ステータスコードは状況に応じて、何を返すかが決まっていますが、
「リソースがない場合」については明確ではないと感じています。
"Webページ"向けの仕様としては、リソースがない場合については404を返すとなっています。
例えば、下記のリクエストで404が返された場合、何の状況なのか考えてみましょう。
GET api.example.com/item/1234
itemに「1234」というものが存在しないのでしょうか？
ではitem/1000だったら通る可能性がありますか？
しかし確認すると1234というitemは間違いなく存在します。
実は/item/という指定が間違っており/items/1234としなければならない状況でした。
こういったケースは往々にしてあると思います。
そのためAPIのURI指定が間違っている(存在しない)場合は404、
URI指定はあっていてもリソースが存在しない場合は別のステータスコードを返す方が
APIを呼び出す側からすると判別がしやすくなります。
では何のステータスコードを返すのがいいでしょうか？
404以外を返したいとはいっても、独自ルールで返すのは余計にわかりにくく混乱を招きます。
候補としては400:Bad Requestと422:Unprocessable Entityが上がってきます。
ステータスコードには値のバリデーションエラー時に返すものとして422があります。
存在しないリソースの指定はバリデーションエラーとみなすことができ、
実際にLaravelなどのフレームワークではバリデーションチェックのルールにリソースの存在判定があり、422になります。
400でもいいのですが、400は構文が無効というような意味合いになり、カバー範囲が広いです。
よって、ルールに則りつつ開発時の問題切り分けがしやすい設計として
リソースが存在しない場合にAPIが返すステータスコードは422を推奨し、次点で400の利用になると考えます。