RESTAPI框架。无效querystring参数的建议行为

我正在实现一个RESTAPI框架，我想知道当客户端提交一个无效的querystring参数时，推荐的行为是什么

我将用一个具体的例子来说明我的意思： 比如说，我在/API/contacts/endpoint上有一个API处理程序，该处理程序提供了一个名为

id

的查询字符串过滤器，它使客户端能够选择具有所提供id的特定联系人

因此，获取或删除请求可以是

/api/contacts/？id=2&id=4&id=lalala

显然，与

id=lalala

的联系是不存在的。在这种情况下，服务器的行为应该是什么样的

• 忽略id为LALA的无效联系人，仅过滤有效id 2和4上的联系人

• 使用指示此错误的错误代码进行响应。如果是，应提供哪些错误代码

提前谢谢

编辑：澄清；我开发的框架的主要重点是具有可预测的行为，因此是响应代码。出于这个原因，我希望使用基于此框架构建的API的客户机能够期待尽可能少的意外。

---

因此，问题基本上是：在这种情况下，API是否应该返回错误（如果是，则返回哪个错误）？或者忽略无效的筛选器条目，仅对正确的查询字符串参数进行筛选？

按照法律规定，响应应为404 Not found。然而，如果你愿意返回400个错误的请求，没有人会对你太不高兴

---

我肯定会返回一个4XX状态码。您希望客户端知道他们犯了错误。

因为这是一个REST调用，所以我们谈论的是资源。每当我们有一个错误的过滤器，我们应该返回一个正确的错误代码

在这种情况下，我会选择

400-错误请求

，因为资源已被找到并正确映射（

/api/contacts

），但是

查询字符串

部分存在问题。因此是

400

而不是

404

如果有人请求

/api/contacts all

或某个不存在的资源，则将返回

404

根据下面的评论进行编辑

同意你的意见。理想情况下，

400

是请求的问题。这样，您可以使用

422不可处理的实体

。请看下面的stackoverflow链接，它谈到了同样的事情

我想世界各地的开发人员会更愿意看到

400

而不是

422

来处理此类逻辑错误，因为大公司使用的是

400

，而不是

422

参考资料： 及

---

Darrel，谢谢您的回复。我不同意您的看法，尽管响应应该是404错误，因为API端点是正确的，并且映射到有效的资源（例如/API/contacts/）。一个400的错误会更有意义，我想：）达雷尔，你肯定有道理。正如你最初所说，尽管按照法律条文的规定，回复可能是404错误，但我更倾向于400错误。拉维，谢谢你的回复。我同意400的错误是很有道理的。唯一阻止我这样做的是，当请求正文中包含无效数据时（例如在PUT/POST请求中），我返回400个错误，这似乎有点违反直觉，但很合理，在这种情况下给出了相同的响应。Ravi，谢谢。非常完整和明确的回应。422错误似乎是最正确的响应，因为请求在语义上不正确。我将更深入地研究它，并尽快与您联系。422是不可处理的实体，但这里的问题是一个查询参数，它不是实体的一部分。我认为404最好。