Restful API 资源未找到应该返回什么状态码？

[zuoakang]

需求是这样的: 查询某个用户是否存在，GET users/zhangshan

我这边使用的是 drf 框架，为了与框架统一，资源未找到返回的状态码都是 404。

与我这边对接的是 java 后台，他们觉得返回 404 会被他们 try cache，认为是请求参数有问题或者 URL 出错，程序不往下走了，而返回 200，response 为空，程序会往下走，而且知道 zhangshan 这个对象为空。

大家觉得资源不存在应该返回什么状态码呢？

[DavidNineRoc]

一直使用这种风格

[BigDogWang]

返回 200 怎么监控服务呢？

[WilliamYang]

我采用的是返回 404，并在 response body 里添加 code 和 message，前端可以知道是 url 错误，还是资源找不到

[liukanshan]

按照 http 状态码来说 4xx 是客户端错误 如果没有拼写错误 只是业务上面的逻辑 可返回 200， 另外这仅仅是一个参考 适合当前业务的才是最好的

[suom]

业务逻辑的资源不存在还是 200 好，不然等业务做大接了 waf 错误码统就废了，运维会吐血。

[chanchan]

http status 是描述 http 协议的不是用来描述业务的

[jadec0der]

如果是 RESTful，那就应该是 404，用 200 也可以，但是别说自己是 RESTful。

[lamada]

支持 200，代表接口请求成功，服务是可用的。然后返回的业务字段里包含 404 信息，代表业务请求失败。

[sazima]

我还是习惯所有的 http 状态码都是 200, drf 封装一下吧.

{
'code': 404,
'msg': 'not found'
}

[shawndev]

这个问题算是 restful 风格的日经帖了，说一下我的看法。

两种方式都可以，也都不能说是错的，建议按照项目目前的设计使用即可。

如果要新写项目或者重构项目，推荐状态码统一 200。

业务的错误很难全部映射到 http 状态码，以至于我们公司后端开发凭空捏造出 6xx 的状态码。

如果通过 message 区分错误，前端需要展示错误是直接展示 message 吗？如果是，依据错误做特殊处理需要判断 message 吧，message 需要国际化怎么办？

[fhy1994]

@DavidNineRoc #61 一模一样

[darknoll]

不是服务端的问题就返回 200，在返回的 json 里面写 404

[meetocean]

RESTful API 中使用 HTTP 状态码来表示请求状态。404 的定义：请求的内容不存在。
如果这个说法是对的，那么找不到资源，都是返回 404 而不是 200。

[Sapp]

数组不存在返回空数组（反 null 的就是坑爹），单个资源不存在就别反了 404 吧，或者返回个 null （反回个空 {} 的也是坑爹）

[limuyan44]

好像都本末倒置了，几十年前的 rest 当宝典一样。。适合项目才是真的好。

[Muninn]

https://zhuanlan.zhihu.com/p/57367932

我写过一篇说这个问题

在公司合作上，支持谁牛听谁的。

在事情的道理上，支持跟随大厂和框架的，这个大厂用 404 的多，框架也不会不能处理，我认为属于前端太懒或者太弱。

[index90]

请搜索 Google API Design Guide 并学习

[glues]

404 是 HTTP 协议的状态码，跟 RESTful 有毛关系？
我发现很多 Java 程序员都搞不清楚 HTTP 协议，主要体现在两点：
1. status code，除了 200，其他一律都是错误，搞得好像非 200 时就不能发 body 一样
2. 搞不清楚 content-type，他文档上说返回的 JSON，结果返回的是 text，甚至还有返回的 text 需要你 JSON parse 两次

[libook]

返回状态按照数据层分级，HTTP 层的状态用 HTTP 层状态码来表示，业务层的状态用业务状态码来表示，比如客户端 abc 参数传错了，这在 HTTP 层看来是“客户端错误”，所以应该返回 400 的 HTTP 状态吗，但同时在业务上来说是 abc 参数错误，所以同时返回 Body 应该用业务状态码或者错误信息告诉客户端究竟是哪里错了。

REST 风格是以资源为中心的，简化接口复杂度，将部分功能降级交由 HTTP 层来表示，对于资源找不到的情况，应该按照 HTTP 的 Not found 状态来表示，即 404 状态码。

REST 设计风格不是说客户端和服务器一方使用的，而是双方都使用的，客户端不管使用什么语言，都应该选用 REST 友好的请求框架来与服务器的 REST 接口通信，否则就不要使用 REST 风格了，不完全按照 REST 的思想来设计不能享受 REST 带来的好处，甚至可能会适得其反。

然后从系统可靠性上来看，不管服务端用的到底是不是 REST 设计风格，客户端都应该对所有 HTTP 层的异常做妥善处理，不是抛错误了事，而是应该处理所有错误情况；而在应用 REST 设计风格的时候，要习惯将 404、403、401 等作为“正常”状态来妥善处理，提升系统高可靠性以及用户友好程度。

最后建议整个开发团队科普一下 HTTP Status Code 标准： https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
表示“成功”的状态是整个 2 段，不只有 200。

[ty89]

我只好奇一点
哪些强烈要求返回 404 的，你们是从来没遇到过神仙路由器劫持 404 的情况吗？