正常動作でも404が返ることを想定したAPIコールは特に問題ないのか

Question

前提・実現したいこと

ある入力の重複チェックのために、Ajaxで自前実装したREST APIを呼んで、200なら内容チェック、404なら存在しない、というように処理を振り分けていました。

ところが、たとえ404が想定どおりであったとしても、Google Chromeのコンソールにエラーとして表示されてしまいます。そこで気になったのですが、

1. このような「正常動作の一環としてAPIが404を返すことを利用する」のは特に問題ない（Chromeのエラーは無視していい）のでしょうか。
2. それとも、正常動作の場合に「存在しない」ものも探すのであれば、別途で「HTTP上では200として返す」リソースを定義したほうがいいのでしょうか。

設計思想的な面ともなってしまいますが、ご回答いただけましたら幸いです。

発生している問題・エラーメッセージ

# Google Chromeのコンソール上に表示
GET http://localhost:3000/api/models/id 404 (Not Found)

（なお、指定されたidのModelは本当に存在しない＆このAPIを存在チェックのために呼んでいる）

Answer 1

404 Not Found

• 10.4.5 404 Not Found - ハイパーテキスト転送プロトコル -- HTTP/1.1

10.4.5 404 Not Found
サーバが、 Request-URI に一致するものを見つけられなかった。 その状態が一時的か恒久的かに拘わらず、与えられる指示はない。 もしサーバが、ある内部に組み込まれているメカニズムを通して、古いリソースが恒久的に利用できず、それを転送するためのアドレスも無いという事を知っていたら、410 (Gone) ステータスコードが使用されるべきである。 このステータスコードは一般に、サーバが何故リクエストが拒否したかを正確には表したく無い時、あるいは他に適切なレスポンスが無い時に使われる。

正常動作の一環としてAPIが404を返すことを利用する

このような「正常動作の一環としてAPIが404を返すことを利用する」のは特に問題ない（Chromeのエラーは無視していい）のでしょうか。

APIが正常動作しているか否かは問題ではありません。
「サーバが、 Request-URI に一致するものを見つけられなかった」というHTTP 1.1の要件を満たしているか否か、です。

Wikipedia で新しい記事を作成する時、既存の記事名と重複しないと当然チェックしているでしょう。
https://ja.wikipedia.org/wiki/Hypertext_Transfer_Protocol にHTTPリクエストし、「404 Not Found」なら新規記事作成処理に入る、という実装は問題ありません。
内部的に、mod_rewrite でURLを書き換えており、実際に「Hypertext_Transfer_Protocol」というリソースが存在しなかっとしても、対外的には存在するかのように振舞うのであれば、「200 OK」を返して問題ないと思われます。

では、「Request-URI に一致するものを見つけたにも関わらず、404 Not Foundを返す」と何が問題なのか。
HTTP仕様に準じたソフトウェアが期待通りに動作しない可能性があります。
例えば、「404 Not Found」なら処理を停止するアルゴリズムのソフトウェアがあったとすれば、「リソースが存在するにも関わらず、404を返すAPI」に対して処理を続行することが出来ません。
具体的にどんなソフトウェアが該当するのかと問われると答えを持ち合わせていませんが、汎用的な実装を目指す場合には、HTTP仕様に準じておくのが妥当と私は考えます。

Re: maisumakun さん

Answer 2

ちょっと状況がわかりかねますが
ajaxを呼び出す側の処理でたいていエラー処理がはいっているので
404を無視してデータを読み続けるという趣旨の質問でしたら得策ではないと思います。

• mypage.htm

$(function(){
  $.ajax({
    "url":"myajax.php",
  }).done(function(data){
    console.log(data);
  }).fail(function(xhr,err){
    console.log(xhr.status);
    console.log(xhr.responseText);
  });
});

• myajax.php

<?PHP
header('HTTP/1.1 404 Not Found');
print 'hoge';
?>

上記、処理はfail側に流れるのでmyajaxの表示するデータは受け取っていますが
適正なフローとは言えません

Answer 3

リソースが存在しないことを示す場合は404応答でも良いと思います。
ただし、本来の意図としては存在するかどうかを問い合わせるものではなく「リソース（があるはずなので）ください」→「そんなリソースはありません(404)」ということになります。
一つ一つにリソースがあるかないか問い合わせるよりも、リソースを一覧で取得できる方がメリットは大きいのではないでしょうか。

また、このやりかたはその後の目的によってはダメな手段です。
たとえば「存在しなければPOSTリクエストでリソースを作る」というときにGETで取得してからPOSTを実行すると、GETの時点では存在しなかったリソースが次の瞬間には発生していることがあります。
こういう場合は、素直にPOSTリクエストを投げてリソースが重複などで作成できない場合にエラーを返すほうが良いと思います。

Comments

[maisumakun]

状況としては、入力補助としての重複チェック（入力するのと同時にリクエストを投げて、存在するかを取っていく）なので、本番のPOSTの際のチェックはもちろん別個で行っています。

Answer 4

個人的な見解です（長くなってしまいました。すみません）

---

「正常動作の一環としてAPIが404を返すことを利用する」のは特に問題ない（Chromeのエラーは無視していい）

Ajaxは、エラーを想定して処理を書きます。
この想定外エラー処理と、今回の質問の「正常動作の一環としてAPIが404を返すことを利用する」ので書いている処理は、コード上そう大差ないものになるかと思います。

javascript側から見たら、想定内404と想定外エラーは、いい意味でも悪い意味でも差がないわけです。

想定外エラー時の処理も、どのように処理するかは言ってしまえば「自由」です。
ですので、想定内404に対して意図した処理を書いてChromeのエラーを無視したとしても、特別問題があるようには思いません。

上記の意味で、「正常動作の一環としてAPIが404を返すことを利用する」は、有かなと思いました。

別視点で、（論点がずれますが）

入力の重複チェック

この機能として考えた場合は、無しだと思いました。

まず「入力チェック」という機能にといて、
「チェックしなくていい」は、「チェックしてOKだった」と同じ結果になるべき、と思うからです。

質問文から読み取れる「入力の重複チェック」は、「入力チェックしなくていい」と「チェックしてOKだった」がまるで別物の結果ですよね。
それで同じ処理に至る（例えばエラーは表示しない、など）のであれば、違和感は拭えないです。
感覚だけの話、、、と言われてしまえばそれまでですが、そういった「感覚」はやはり人それぞれなので、感覚に寄って仕様に誤解を生む可能性のある作りは、避けるべきなのではないかと思います。

それと、稀だとは思いますが、
本来応答があるべきAPIでも想定外404になる可能性も、0ではないと思います。（「絶対ない」は、言い切れないと思うので・・）

入力チェックは、システム上大事な機能だと思うので、意図して戻ってきた404なのか、想定外404なのかの判断も必要になるなら、「正常なもの」は全部200で返した方が手っ取り早いです。

実際にはPOST後もちゃんと入力チェックしてるから、あくまで補助機能・・・ということであれば、「404はチェックしませんよ。」の単純処理でも最終的には問題がない形におさまると思うので、「想定外404、想定内404の判断」については仕様次第かもですが。

---

正常動作の場合に「存在しない」ものも探すのであれば、別途で「HTTP上では200として返す」リソースを定義したほうがいい

これが出来るなら、そうするに越したことは無いと思います。

想定内でも、404を戻してしまえば、アクセスログには404エラーが残ることになりますし、
「404が戻ってくる可能性を分かったうえで、同じURLに何度もリクエストを投げる」
内部的な話は置いて、これだけを聞いたら
「404になるかもしれないリンクが、いつでもサイト上に堂々と置いてある」
というのと大差ないような気がして、
どう頑張っても「いい作りですね」とは言えないのではないかな・・・と思いました。