クエリ文字列が必要だとしましょう。たとえば、「アイテムミッド」。そのクエリ文字列が何らかの理由で欠落している場合、ユーザーに 200 エラー ページまたは「404 Not Found」を表示する必要がありますか?
私は404を支持しますが、よくわかりません。
クエリ文字列が必要だとしましょう。たとえば、「アイテムミッド」。そのクエリ文字列が何らかの理由で欠落している場合、ユーザーに 200 エラー ページまたは「404 Not Found」を表示する必要がありますか?
私は404を支持しますが、よくわかりません。
たぶん、「400 Bad Request」を出す必要があります。
構文が正しくないため、サーバーは要求を理解できませんでした。クライアントは、変更なしでリクエストを繰り返すべきではありません。
その他の可能性については、 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlを参照してください。
そして、クリス・シンプソンが言ったように、対応するアイテムIDのアイテムが見つからない場合、「404 Not Found」を返します。
また、一般的な RESTful API をチェックして、他の人がどのように問題を処理したかを確認することもできます。たとえばTwitter。
良い質問。個人的には 200 を使用して、問題を説明するユーザーフレンドリーなエラーを提供しますが、実際には状況によって異なります。
彼らが itemid を提供したが、特定のアイテムが存在しなかった場合、404 も表示しますか?
ユーザビリティの観点からは、どちらとも言えません。
ユーザーに問題点を伝え、修正する機会を与えるページを表示する必要があります。
リンクがあなたのサイト (または別のサイト) の別のページからのものである場合、要求されたアイテムが見つからなかったことを伝え、適切なページ (おそらくアイテムを閲覧できるページ) にリダイレクトするページでしょうか?
ユーザーが自分でクエリ文字列を入力している場合、その理由を尋ねる必要がありますか? 通常、URI はユーザーフレンドリーではないためです。
取得した HTTP リクエストが適切なレスポンスで応答された場合にのみ、ユーザーに 200 を与える必要があります。これは、パラメーターが欠落しているという単なる HTML であっても同様です。404 コードは、ユーザー エージェントが不足しているリソースを要求しているときです。
詳細については、このリストを確認してください http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
500 エラー、おそらく 501 を返します。これにより、ブラウザーまたはコードは、独自の方法でリッスンする代わりに、既存の onError メカニズムを介してエラーを処理できます。
これが機能しているのを見ると、200 を返す必要があります。これは有効なリソースである必要があるためです。
URL の 1 つがwidgets.com/browse.php?itemid=100
- で、その URL がカタログ内の特定のアイテムを表示するとします。
ここで、ユーザーが入力widgets.com/browse.php
します。アクションはどのようなものになると予想されますか? もちろん、カタログ内のすべてのアイテムを一覧表示するには (または、少なくともページ付けされたリスト)。
URL 構造を再考し、ディレクトリ レベルとパラメータの相互関係を再考してください。