如果通过REST调用传递的错误参数会引发错误吗？

Question

我正在访问REST调用，当我向GET请求传递错误的参数时，它不会抛出任何http错误。如果设计被更改为抛出http错误或错误的参数可以传递给REST调用。

示例1 :(参数是可选的） https://example.com/api/fruits?fruit=apple

列出所有苹果元素

示例2： https://example.com/api/fruits?abc=asb

列出所有水果

我的问题与示例2有关，示例2应该抛出错误还是表现正常？

Answer 1

忽略您不一定期望的参数是很常见的。我认为例2的表现应该如此。

我知道根据浏览器，我有时会附加一个带有时间戳的额外变量，以确保不会缓存其余的调用。类似的东西：

https://example.com/api/fruits?ihateie=2342342342

如果您没有明确地使用额外参数做任何事情，那么我无法看到允许它的伤害。

Answer 2

对于GET请求，request-line is defined如下

request-line   = 'GET' SP request-target SP HTTP-version CRLF

其中 request-target ＆＃34; ...标识应用请求的目标资源＆＃34;。

这意味着路径/api/fruits，问号?和查询abc=asb是所有标识符的一部分。

您的实现碰巧使用路径将请求路由到处理程序，而查询提供参数这一事实是您当前实现的意外。

这让你可以自由决定

1. /api/fruits?abc=asb确实存在，其当前状态是所有水果的列表
2. /api/fruits?abc=asb确实存在，其当前状态为空列表
3. /api/fruits?abc=asb确实存在，其当前状态是其他
4. /api/fruits?abc=asb 不存在，并且尝试访问其当前状态是错误。

  

我的问题与示例2有关，示例2应该抛出错误还是表现正常？

如果abc=asb表示客户端存在某种错误，则应返回4xx状态以指示该错误。

另一种考虑参数处理的方法是Must Ignore vs Must Understand。

实际上，如果我的消费者希望我的过滤器会产生一个小的结果集，而我最终会从消防水管中饮用十亿个未经过滤的记录，我会这样做。不会幸福。

我建议您在输入错误的情况下找到安全失败的方法。在网络上，这可能意味着404，HTML表示解释问题，枚举公认的过滤器，可能包括帮助重新发送查询的Web表单等。以任何有意义的方式将其转换为您的API。

但是选择将其视为一个成功的请求并返回一些表示也工作，它仍然是REST，网络将转向网络。如果这样做可以让消费者获得更好的体验，从而提高采用率并使您的api更加成功，那么答案很简单。