在我的Rest应用程序中，资源url还支持查询参数，如pageSize，pageNum，name等。所以请求网址看起来像
/资源/ {ID}页次= 1＆安培;？的pageSize = 25＆安培; DESC = “你好”
现在假设客户端添加了一个额外的查询参数，例如我的服务器不支持的“lang”，如
/ resource / {id}？pageNum = 1＆amp; pageSize = 25＆amp; desc =“hello”＆amp; lang =“eng”，但我的服务器不支持任何 lang 参数。
什么应该是最好的设计决定
选项1：忽略额外的无效查询参数并提供请求。
选项2：向客户端抛出错误的请求消息。
先谢谢 辛格拉
答案 0 :(得分：5)
毫无疑问，客户必须坚持使用Api文档。
但是APis中的某些变化呢（只是一个小的变化，不涉及迁移到新的API版本）
比如说，一个API资源：/ dummy / api / Iid1支持3个查询参数，即a，b，c
所以完整的URi：/ dummy / api / Id1？a = 1＆amp; b = 20＆amp; c = 45是API公开的有效请求，所有查询参数，即a，b，c都是可选的参数， 即如果请求中不存在这些参数，则服务器将它们处理为某个默认值，如a = 0，b = 0，c = 0
在某些时候，大量客户端基于上述URL方案构建其应用程序。
现在API提供商想要废弃参数'b'并决定在额外/未知参数上抛弃异常
这意味着所有客户端应用程序围绕涉及参数“b”的最后一个URL方案构建将失败！
这只是表明，抛出额外/未知查询参数的异常总是会导致客户端和服务器问题的紧密耦合，我想这完全违背了 REST原则，可能有一个中心主题，即“完全分离客户端和服务器问题，以便两者可以分开发展”
所以我认为只有缺失/无效的'强制'参数应该抛出异常，而不是选项，永远不会。
答案 1 :(得分：4)
请忽略它。大多数其他Web服务器会忽略它不理解的请求参数。
Google在此处忽略了我的两个额外参数 https://www.google.com/#q=search+for+something&invalid=param&more=stuff
答案 2 :(得分：3)
我想忽略不良参数是标准做法，但在很多情况下我似乎完全错了。
假设我有一个小部件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状态，并显示一条错误消息，指出＆＃34; foi＆＃34;不是公认的参数？这似乎尤其正确，因为对于请求体中的同类错字，最佳行为是返回400.（例如，请参阅此答案：https://stackoverflow.com/a/20686925/2716301）
答案 3 :(得分：1)
忽略它是常见模式，但查询参数也是URL（资源ID）的一部分，并且此类请求上的正确响应代码为404 Not Found。
没有一般的设计模式。你必须问自己什么对你的用户最好。最好告诉他们他们所要求的资源不是以他们需要的格式提供，或者只是给他们另一种资源？
注意
HTTP包含处理语言的强大机制;请参阅Accept-Language和Content-Language标题（所有浏览器都在使用它）