考虑一个RESTful API，它接受列出项目的GET请求：
GET /1.0/items/
>> {"items": [{}, {}, ..., {}]} # All items returned
现在考虑每个项目都有一个颜色字段，我可以过滤我的项目：
GET /1.0/items?color=blue
>> {"items": [{}, {}, ..., {}]} # Only blue items returned
如果我的API收到无效查询参数（不是有效查询参数的无效值）：
GET /1.0/items?notvalid=blue
预期的行为应该是什么？我的API应该返回4xx响应，通知客户端请求是无效的，还是API应该执行项目列表，就好像没有提供过滤器参数一样？
答案 0 :(得分：2)
我的API是否应该返回4xx响应，通知客户端请求无效，或者API应该执行项目列表，就好像没有提供过滤器参数一样？
/1.0/items?notvalid=blue标识资源。此标识符可以解释为分层部分和查询（请参阅RFC 3986, section 3），但标识符是整个事物。面向不存在的资源的URI的文档存储将响应404错误。所以这种行为是完全可以接受的（人们也可以使用更一般的400错误，但这并不常见）。
另一种有价值的方法是使用must ignore政策。将URI视为键值对的x-www-form-urlencoded表达式，可以liberally accept查询，忽略无法识别的键，并为缺少的任何键提供默认值。
采用这种方法，这个标识符将被视为拼写/1.0/items?这样可以防止变更（客户和服务器不需要完全同意取得进展）。< / p>
注意：在REST中 - 客户端通常会使用超媒体表示来引导它完成协议;因此，客户端将通过表单或uri模板发现哪些参数是预期的查询字符串的一部分。这实际上只是必须忽略的语义，但在不同的地方应用。
API应该执行项目列表，就好像没有提供过滤器参数一样吗？
您可能希望明确标识要返回的引用，以便客户端可以检测到差异;例如，通过将请求重定向到您要返回的标识，或者返回Content-Location标题。
答案 1 :(得分：1)
根据JSON API文件：
在大多数情况下，JSON API要求服务器在遇到JSON API定义的查询参数的无效值时返回错误。但是，对于特定于API的查询参数（即那些未由JSON API定义的参数），服务器可能会选择忽略无效参数并使请求成功，而不是回复错误。
这是我通常在API上看到的行为。