9

在我的 Rest 应用程序中，资源 url 还支持 pageSize、pageNum、name 等查询参数。所以请求 url 看起来像

/resource/{id}?pageNum=1&pageSize=25&desc="hello"

现在假设客户端添加了一个额外的查询参数，比如我的服务器不支持的“lang”

/resource/{id}?pageNum=1&pageSize=25&desc="hello"&lang="eng"，但我的服务器不支持任何lang参数。

什么应该是最好的设计决策

选项 1：忽略额外的无效查询参数并提供请求。

选项 2：向客户端抛出错误的请求消息。

提前致谢

4

4 回答 4

7

毫无疑问，客户必须遵守 Api 文档。

但是 API 中的某些更改呢（只是不涉及迁移到新 API 版本的小更改）

比如说一个API资源：/dummy/api/Iid1支持3个查询参数，即a、b、c

所以完整的 URi : /dummy/api/Id1?a=1&b=20&c=45 是 API 公开的有效请求，所有查询参数，即 a、b、c 都是可选参数，即如果这些参数不存在在请求中，然后服务器将它们处理为一些默认值，例如 a = 0, b = 0, c= 0

一段时间以来，大量客户端基于上述 URL 方案构建他们的应用程序。

现在 API 提供者想要取消参数“b”并决定在额外/未知参数上抛出异常

这意味着所有客户端应用程序围绕最后一个涉及参数“b”的 URL 方案构建将失败！

这只是表明，为额外/未知的查询参数抛出异常总是会导致客户端和服务器问题的紧密耦合，我猜这完全违反了 REST 原则，这可能有一个中心主题是“完全分离客户端和服务器问题，因此两者都可以单独发展'

所以我认为只有丢失/无效的“强制”参数应该抛出异常，而不是选项，永远不会。

于 2013-04-11T17:06:45.333 回答
6

忽略它。大多数其他 Web 服务器会忽略它不理解的请求参数。

谷歌在这里忽略我的两个额外参数 https://www.google.com/#q=search+for+something&invalid=param&more=stuff

于 2013-04-11T11:10:01.233 回答
3

我想忽略错误参数是标准做法，但在很多情况下对我来说似乎完全错误。

假设我有一个带有小部件集合端点的小部件 API，它可以找到小部件。小部件具有 foo 属性，因此以下搜索 foo = bar 的小部件

GET https://example.com/widgets?foo=bar

现在一个 API 客户端打错了。

GET https://example.com/widgets?foi=bar

不是只返回 foo = bar 的小部件，而是默默地忽略拼写错误并返回所有小部件（适当地限制为某个默认大小，因为我制作了精心设计的 API）。我的 API 客户端可能会花费数小时试图弄清楚为什么她的电话不起作用，或者更有可能点亮我的支持站点，想知道为什么我的 API 很糟糕。

返回 400 状态并显示错误消息指出“foi”不是可识别的参数不是更好吗？这似乎尤其正确，因为对于请求正文中的同类错字，最佳行为是返回 400。（例如，请参阅此答案：https ://stackoverflow.com/a/20686925/2716301 ）

于 2016-12-03T17:38:38.467 回答
0

忽略它是常见的模式，但查询参数也是 URL（资源 id）的一部分，这种请求的正确响应代码是 404 Not Found。

没有通用的设计模式。您必须问自己什么对您的用户最有利。更好地告诉他们他们所要求的资源没有以他们需要的格式提供，或者只是给他们另一种资源？

笔记

HTTP 包含很好的语言处理机制；请参阅 Accept-Language 和 Content-Language 标头（所有浏览器都在使用它）

于 2013-04-11T14:59:37.697 回答