如何处理包含API未使用的参数的URI？

Question

在REST接口中，我是否应该显式地检查客户机是否只使用API使用的参数，如果请求中包含了API不知道的参数，则返回HTTP 403？

有一点背景。我正在开发一个API，它可以缩小JavaScript和更少的文件。最初，使用Google闭包编译器对JavaScript文件进行了精简。由于闭包编译器有多个优化级别(仅使用空格、简单优化和高级优化)，因此API还使调用方能够指定(可选)级别，因此：

POST http://example.com/api/v1/js?level=whitespace

以及：

POST http://example.com/api/v1/js?level=advanced

在大多数情况下会产生不同的结果。

最近，我不得不添加对ES6的支持。考虑到闭包编译器对ES6缺乏适当的支持，我添加了YUI压缩器。由于这一次没有优化级别，所以调用现在很简单：

POST http://example.com/api/v1/es6

在波拉之后，我的印象是我不能让调用者像这样使用API：

POST http://example.com/api/v1/es6?level=advanced

因为他们希望得到一个具体的结果，但却得到了不同的结果。解决方案是检查URI中是否存在level参数，并返回一条错误消息，指示不支持该参数。

但是我检查了这个特定的参数，为什么不检查一下lecel (一个错误)，或者optimize (猜测)，或者其他什么呢？

因此，API期望参数a、b和c可能包含在URI中吗?如果URI还包含d或e，那么响应应该是什么？

Answer 1

我要说的是，你目前的做法是遵循最不惊讶的原则。

首先，您在v1下定义了两种不同的资源: js和es6。它们没有理由接受相同的查询参数，这些参数有助于资源的表示。

然而，你在想，因为所有这些都是js-最小化器，它们会接受相同的参数。事实上，不同的最小化器需要不同的参数并不令人惊讶。

另一个例子是，API使用者非常习惯不同的路线需要不同的参数，他们通常没有透明的改变资源和保持相同的参数。对于大多数API来说，这个规则的例外可能是一些身份验证参数或分页参数，但这是一个例外，因为它处理的是作为应用程序范围责任的横切关注点。

在你的例子中，没有一个是直接适用的。我认为你目前的设计感觉更自然，让人惊讶更少。

Answer 2

由于您已经有了API的版本(意思是，不存在向后/向前兼容性问题)，所以最符合逻辑的是验证输入，并在意外参数上给出400 (糟糕的请求，非常通用)、422 (非可处理实体)，这是一些人认为比400要好的地方，如下所示。不太适用的是404 (未找到)--因为找到了es6，或者在非常罕见的情况下，甚至501 (未实现)。

使用4xx HTTP代码将节省用户对API访问的故障排除时间。

还请参阅这里 (422也建议)或这里，这说明了422可能更合适的原因。也请参阅这个问题。

就我个人而言，我贴上了400和广谱的HTTP代码。

根据用例的不同，某些查询字符串参数可能是可以忽略的，例如，下划线前缀参数，用于防止缓存的唯一方法是更改URL以包含“指纹”。

Answer 3

level=...似乎是向后兼容的问题。为了不让当前用户感到沮丧，我会检查级别，因为它在以前的版本中实际上做了一些事情，但是在当前版本中没有做任何事情，并给出警告消息("level是不推荐的，当前什么都不做“)--但是不能停止处理。我会将错误作为JSON响应的一部分，而不是http错误。我通常会为防止处理的错误保留这些。

如果您所支持的内容有可能发布个人日期(医疗保健或信用)，那么对于额外的或拼写错误的变量，我将不会返回任何内容。如果他们足够坚持，他们就会解决这个问题。

如果没有泄露机密信息的机会，那么请提供您想要的具体错误/警告。在这种情况下，我会将警告消息放在JSON响应中，因为它不会影响将要发生的处理。

在这两种情况下，您都应该检查传入的所有变量和值，以确认是否存在跨站点脚本或sql注入或任何其他安全问题。