私はRESTful APIを作成しています。私は、 'Junk'クエリパラメータを処理するためのRESTfulな方法が何であるか不思議です。現在、返されるデータを制限するパラメータがあります。RESTfulなAPIと迷惑クエリ文字列
my.api.com/v1/users?limit=2
しかし、私はどちらかのスペルの間違いを受け取る代わりに、場合
my.api.com/v1/users?limti=2
または
my.api.com/v1/users?order=asc
私は通常、エラー応答の方法を使用しますが、私は多くのWebサイト/サービスが間違ったパラメータを無視することに気付きます。
クエリパラメータは、リソースの識別子の一部です。クエリコンポーネントは、パスコンポーネント（3.3節）のデータと共に、URIのスキームの範囲と命名権限（存在する場合）内のリソースを識別するのに役立つ、非階層データ含まRFC-3986
参照。クエリコンポーネントは、最初の疑問符（ "？"）文字で示され、数字記号（ "＃"）文字またはURIの終わりで終了します。
したがって、
GET my.api.com/v1/users?limti=2
に応じて尋ねるべき重要な質問です：は、このリソースが存在しませんか？
私には、そのURIはクライアントエラーのように見えます。 Iは、私の望むものではない恣意的な応答を私に返すのではなく、私が作った間違いをエンドポイントに通知することが望ましいです（404は適切と思われます）。 "Fail fast"は問題をより簡単に発見します。
しかし、「はい、そのリソースは存在します - ここにそれを表現しています」と言って、あなたの好きなものを返すだけでも有効です。それは役に立ちませんが、間違っているわけでもありません。結局のところ、私のスペルミスがあなたのシステムのリソースのスペルに実際に合う運があったなら、あなたがやることになるでしょう。私が望んでいたこと（両方の世界の最悪かもしれない）の妥協があなたの本当のリソースにクライアントをリダイレクトすることですmy.api.com/v1/suers?limit=2
たとき、あなたのAPIは私がmy.api.com/v1/users?limit=2を求める際に行うために何が起こっているか、例えば、考えてみましょうシステム。たとえば、order = ascパラメータを無視するだけの場合は、その表現を任意に戻すのではなく、クライアントをmy.api.com/v1/usersにリダイレクトするほうが面白いかもしれません。
間違いなく両方の世界の最悪！ –
この記事を参照してください。これは、REST APIとクエリパラメータに関する多くの情報を持っています。http://stackoverflow.com/questions/4024271/rest-api-best-practices-where-to-put-parameters –
おそらく、いくつかのデフォルトを使用して終了するでしょう。そのうちのいくつかは、制限パラメータが不足していて10000000レコードを返すことを望まないし、いくつかのコンビネーション（ORDER BY）を返すこともないからです。 パラメータが正しくない場合は404を返しません。404はリソースが存在しないことを意味します。 – Borjante