我应该允许未知的参数吗？

我正在设计一个RESTful API，并遇到标题问题，为清楚起见已重述：

如果客户端发送无法识别的参数，我应该快速失败吗？例如，

http://example.com/api/foo?bar=true&paula=bean

在上面，bar是有效参数，但paulaAPI未指定。我是不是该

警告客户错误
快速失败
忽略它

如果我警告客户端，我只能对第一个参数发出警告，因为它们可能发送的数量几乎是无限的，并且服务器可能要做的更好。同样，失败时，只会将第一个无效参数指定为问题。

我更喜欢失败而不是发出警告来迫使程序员采取行动，因为否则他们可能会忽略问题并继续浪费资源，或者最终不经意地养成自己。在这方面什么都不做会更糟。

我的论点有意义吗？在这种事情上有公认的做法吗？

rest api-design

— 拉斯
source

根据一项小型测试，我测试的所有站点都只是忽略了我为其提供的未知参数。

— Bart van Ingen Schenau'3

@BartvanIngenSchenau这里也是。对于网页来说很好，但我认为对于实际的API来说

— 还不行

一个问题是前向兼容性。如果忽略了未知参数，则可以在将来的版本中使用它们，以便客户端可以编程到新API并在旧服务器上仍然获得合理的行为。

— walpen '16

@walpen这是一个有趣的观点。使用版本化的URL api/v1等可以解决这个问题，但是仍然不允许增量更新。+1

— 拉斯

在这里，您可以从实际的角度找到一些优缺点：严格参数和您的API。

— Remek Ambroziak

Answers:

我认为，您应该返回“无效请求”状态，以便客户端知道它要执行的操作无效。我对此的看法受RESTful API是可发现的概念的影响。如果您预先提供了足够的信息，则客户端永远不会尝试提出无效的请求。如果是这样，则客户端代码中有问题，并且快速失败将使第二个警告此错误。当然，这是一种非常纯粹的方法，如果无法发现您的API，可能不建议您这样做。

更为实用的方法可能是忽略无效的参数，但是无论采取哪种方式，请务必将行为记录在案。

— 橡皮鸭
source

作为扩展：如果客户端发送一些未知/只读/不推荐使用的参数，则意味着该客户端期望某些行为无法实现。因此执行任何动作都是危险的。所以我同意，严格错误的请求

— 斯捷潘·斯捷潘诺夫

感谢@StepanStepanov，但是在Web的许多体系结构中都存在“宽容您所接受的内容，明确说明所发送的内容”的理念。考虑到这一点，我可以轻松地写一个与我已经写过的答案相反的答案。

— RubberDuck

我已经在Google上搜索了）），有关Postel法则的页面也说“只要含义清楚，接收输入的代码就应该接受不合格的输入”。我认为，如果客户向我们发送了一些未知参数，则其含义尚不清楚。如果客户向我们发送了一个不推荐使用的参数，则很明显，它将无法像以前一样或如客户期望的那样工作。如果客户向我们发送了一个只读参数，则很明显，它将不会按照客户的要求写入。

— Stepan Stepanov

如果您使用公共API（或其他团队将使用的api），我建议按照@RubberDuck的建议返回错误。

如果您的API仅在团队内部使用（或仅由您自己使用），则忽略其他字段可能会更容易（例如，需要更少的代码并且更容易做到）。

— 康斯坦丁·彼得鲁赫诺夫（Konstantin Petrukhnov）
source