- 状态码
400 Bad Request
当客户端发送了一个由于格式错误而无法处理的请求时使用。 - 状态码
404 Not Found
当请求的资源不存在/找不到时使用。
我的问题是,当客户端向我的 API 不提供服务的端点发送请求时,这些状态代码中哪个更合适?
是否应将端点视为“资源”,并因此返回 404
?我的问题是,如果客户端只检查状态代码,他们无法区分 404
表明他们到达了正确的端点,但没有匹配他们的查询的结果,与404
表示他们查询了一个不存在的端点。
或者,我们是否应该期望客户端事先了解所有可用的 API 端点,从而将他们的请求视为格式错误并返回 400
如果他们是试图到达不存在?
也许这取决于端点是否为 REST。如果它们是 REST 端点,则客户端不需要先验 API 知识,但能够通过从单个根端点导航 API 来了解所有相关的 API 端点。在这种情况下,我想 404
会更合适。
在我现在的具体情况下,这是一个内部(非 REST)HTTP API,我希望客户端事先了解所有 API 端点,所以我倾向于 400
,避免 404
从访问错误的端点可能被误解为 404
表明无法找到他们从正确的端点寻求的内容。
想法?
最佳答案
为方便起见,许多现代 API 都提供了人类可读的端点,以方便开发人员。然而,REST 的意图是将 URL 视为不透明的——它们可能恰好包含语义内容,但不能依赖于这样做。没有“格式错误”的 URL 这样的东西。只有一个指向某物的 URL 和一个不指向某物的 URL。
现在,这就是 REST 教条(也可以说是 HTTP 1.1 规范)。这并不意味着这是你应该做的。如果您的 API 有一个内部客户端,并且这种情况不会改变,那么您在设计自己的标准时就有很大的灵 active 。只要确保将它们记录下来,尤其是那些可能会让刚从大学毕业的人感到困惑的人,他们会在你离开时雇用他们来代替你。
关于HTTP 状态 404 或 400(如果不存在此类 API 端点)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45098651/