私のRestアプリケーションでは、リソースURLはpageSize、pageNum、nameなどのクエリパラメーターもサポートしています。したがって、リクエストURLは次のようになります
/resource/{id}?pageNum=1&pageSize=25&desc="こんにちは"
ここで、クライアントが、サーバーがサポートしていない「lang」などの追加のクエリパラメーターを追加するとします
/resource/{id}?pageNum=1&pageSize=25&desc="hello"&lang="eng"ですが、私のサーバーはlangパラメータをサポートしていません。
最良の設計上の決定は何であるべきか
オプション 1 : 余分な無効な queryparam を無視して、リクエストを処理します。
オプション 2 : 不正な要求メッセージをクライアントにスローします。
よろしくお願いします
クライアントが Api ドキュメントに固執しなければならないことは間違いありません。
しかし、API の特定の変更についてはどうでしょうか (新しい API バージョンへの移行を伴わない小さな変更のみ)。
たとえば、API リソース: /dummy/api/Iid1 は 3 つのクエリ パラメータ、つまり a、b、c をサポートします。
したがって、完全な URi : /dummy/api/Id1?a=1&b=20&c=45 は API によって公開される有効な要求であり、すべてのクエリ パラメータ、つまり a、b、c はオプションのパラメータです。つまり、これらのパラメータが存在しない場合リクエストで、サーバーはそれらをa = 0、b = 0、c = 0などのデフォルト値に処理します
しばらくすると、多数のクライアントが上記の URL スキームに基づいてアプリケーションを構築します。
ここで、API プロバイダーは、パラメーター 'b' を廃棄したいと考えており、余分な/不明なパラメーターで例外をスローすることを決定します
これは、パラメータ 'b' を含む最後の URL スキームを中心に構築されたすべてのクライアント アプリケーションが失敗することを意味します。
これは単に、余分な/不明なクエリ パラメーターに対して例外をスローすると、常にクライアントとサーバーの懸念が密接に結び付いていることを示唆しています。これは、REST の原則に完全に反していると思われます。サーバーの懸念、両方が別々に進化できるように」
したがって、欠落/無効な「必須」パラメーターのみが例外をスローする必要があり、オプションのものでは決してスローされるべきではないと思います。
無視してください。他のほとんどの Web サーバーは、理解できない要求パラメーターを無視します。
Google はここで私の 2 つの追加パラメータを無視します https://www.google.com/#q=search+for+something&invalid=param&more=stuff
無視するのが一般的なパターンですが、クエリ パラメータも URL (リソース ID) の一部であり、この種の要求に対する適切な応答コードは 404 Not Found です。
一般的な設計パターンはありません。ユーザーにとって何が最善かを自問する必要があります。彼らが求めているリソースが必要な形式で利用できないことを伝えるか、単に別のリソースを提供する方がよいでしょうか?
ノート
HTTP には、言語を処理する優れたメカニズムが含まれています。Accept-Language および Content-Language ヘッダーを参照してください (すべてのブラウザーで使用されています)。