在我的 Rest 应用程序中，资源 url 还支持 pageSize、pageNum、name 等查询参数。所以请求 url 看起来像
/resource/{id}?pageNum=1&pageSize=25&desc="hello"
现在假设客户端添加了一个额外的查询参数，比如我的服务器不支持的“lang”
/resource/{id}?pageNum=1&pageSize=25&desc="hello"&lang="eng" ，但我的服务器不支持任何 lang 参数。 p>
什么应该是最好的设计决策
选项 1：忽略额外的无效查询参数并处理请求。
选项 2：向客户端抛出错误的请求消息。
提前致谢 辛拉
【问题讨论】：
标签： java web-services api rest resteasy
忽略它。大多数其他 Web 服务器会忽略它不理解的请求参数。
Google 在这里忽略了我的两个额外参数 https://www.google.com/#q=search+for+something&invalid=param&more=stuff
【讨论】：
忽略它是常见模式，但查询参数也是 URL（资源 id）的一部分，此类请求的正确响应代码是 404 Not Found。
没有通用的设计模式。您必须问自己什么对您的用户最有利。更好地告诉他们他们所要求的资源没有以他们需要的格式提供，或者只是给他们另一种资源？
注意
HTTP 包含很好的语言处理机制；查看 Accept-Language 和 Content-Language 标头（所有浏览器都在使用它）
【讨论】：
毫无疑问，客户必须遵守 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 原则，其中心主题可能是“完全分离客户端和服务器关注点，以便两者可以单独发展”
所以我认为只有丢失/无效的“强制”参数应该抛出异常，而不是选项的，永远不会。
【讨论】：
我想忽略错误的参数是标准做法，但在很多情况下，这对我来说似乎是完全错误的。
假设我有一个带有小部件集合端点的小部件 API，它可以找到小部件。小部件具有 foo 属性，因此以下搜索 foo = bar 的小部件
GET https://example.com/widgets?foo=bar
现在一个 API 客户端打错了。
GET https://example.com/widgets?foi=bar
不是只返回 foo = bar 的小部件，而是默默地忽略拼写错误并返回所有小部件（适当地限制为某个默认大小，因为我制作了精心设计的 API）。我的 API 客户可能会花费数小时试图弄清楚为什么她的呼叫不起作用，或者更有可能点亮我的支持网站，想知道为什么我的 API 很糟糕。
返回 400 状态并显示错误消息指出“foi”不是可识别的参数不是更好吗？这似乎尤其正确，因为对于请求正文中的同类错字，最佳行为是返回 400。（例如，请参阅此答案：https://stackoverflow.com/a/20686925/2716301）
【讨论】：