REST API フレームワークを実装していますが、クライアントが無効なクエリ文字列パラメータを送信した場合の推奨動作は何でしょうか。
具体的な例で説明しましょう。たとえば、/api/contacts/ エンドポイントに API ハンドラーがあり、そのハンドラーが という名前のクエリ文字列フィルターを提供するとしますid。これにより、クライアントは提供された ID を持つ特定の連絡先を選択できます。
したがって、GET または DELETE リクエストは次のようになります/api/contacts/?id=2&id=4&id=lalalala。
明らかに、 との Contact というものは存在しませんid=lalalala。この場合、サーバーはどのように動作するべきでしょうか?
無効な連絡先を無視し
id=lalalala、有効な ID 2 と 4 の連絡先のみをフィルターします。このエラーを示すエラー コードを応答してください。はいの場合、どのエラー コードを指定する必要がありますか?
前もって感謝します。
編集: 明確にするために、私が開発するフレームワークの主な焦点は、予測可能な動作と応答コードを持つことです。このため、このフレームワーク上に構築された API を使用するクライアントが、できるだけ驚きを期待しないようにしたいと考えています。したがって、質問は基本的に次のようになります。この場合、API はエラーを返す必要がありますか (そうであれば、どのエラーを返すか)? または、無効なフィルター エントリを無視し、正しいクエリ文字列パラメーターのみをフィルターしますか?
ベストアンサー1
これは REST 呼び出しなので、リソースについて話していることになります。間違ったフィルターがある場合は、適切なエラー コードを返す必要があります。
400 - bad requestこの場合、リソースは見つかって正しくマップされています/api/contactsが ( )、パーツに問題があるため、を選択しますquery string。したがって、 では400なく です404。
404誰かがリクエストした場合/api/contacts-all、または存在しないリソースがあった場合は を返します。
以下のコメントに基づいて編集
あなたのコメントに同意します。理想的には、 は400リクエストの問題です。それに基づいて、 を使用できます422 Unprocessable Entity。以下の stackoverflow リンクを見てください。同じことについて書かれています。
大企業が ではなくを使用しているという事実から、世界中の開発者はこのような論理エラーに対して400よりもを見る方が安心するだろうと推測します。422400422