RESTful 的增删改查成功应该返回什么状态码?

[Vimax]

RESTful 的 GET POST PUT DELETE 如果操作成功应该返回什么状态码呢?

用 200,201,202,204 代表 4 种请求的成功合适吗?

请求成功

• GET 200 OK
• POST 201 Created
• PUT 202 Accepted
• DELETE 204 No Content

如果 GET POST PUT 　 DETELE 请求,数据库执行结果都为 0.又如何返回 HTTP 状态码呢?

是返回 404 not found 吗?

另外一个问题

请求方式的数据类型: GET 和 DELETE 是否[不能]或[不推荐]使用 JSON 数据的形式.

前端使用的是 VUE axios 发送请求,之前 DELETE 发送 JSON 数据,后端无法接收到.

目前 4 种请求方式对应使用的数据类型是:

• GET application/x-www-form-urlencoded
• POST [ "application/json;charset=UTF-8" ]
• PUT [ "application/json;charset=UTF-8" ]
• DELETE application/x-www-form-urlencoded

[newtype0092]

@jones2000 别问，问就是需求不合理。
什么样的需求才叫合理？只提标准 RESTful 能直接实现的需求，其他的不做就完事了。
你看 XX 大厂 RESTful 都能满足需求，你们需求还能比人家复杂？

可以和同行讨论观点，不要和教徒争论信仰。

[jones2000]

@newtype0092 谁发我工资 谁的需求就合理。 我只是打工的， 只会具体到一个一个需求的实现才能拿工资糊口。太空泛的概念对我没什么用， 还是要能实现具体需求才行呀。哪有直接对老板说你的需求不合理，不做。现在工作不好找难呀。

[lihongming]

全用 http code 做状态码是一种理想，实际很难做到，因为你总会有一些非标准的或是需要细分的状态。

所以还是 http 的归 http，业务的归业务就好，不要被那些鼓吹纯 http code 的人吓到，须知任何事情走向极端都是邪教。更何况很多大公司的 API 也在这么做（比如 amazon ），你不是一个人！

[hantsy]

@jones2000 如果我没记错的话，V 站几乎都是 Spring 。Spring 的 ExceptionTranslator 会将所有的所有的数据库异常翻译成相应的 DataAcessException （子类），而在 Spring Boot 中所有的内置的异常 Spring 已经处理了。

数据库异常问题，这类的系统问题根本就不应该丢给前端，常识，自己从项目一开始就要有自己的日志分析处理系统，监控日志。

再说了，你的这些例子就是程序错误，你们不写测试吗？

[IvanLi127]

@zhuweiyou #14 那是掉队的野生前端吧

[crclz]

200：成功
401：Unauthorized 未登录
403：Forbidden 没权限操作资源
404：NotFound，一是由框架在无法匹配路由时抛出，二是当 PATCH or DELETE /article/{id}时 id 找不到的时候返回。
400：其他错误情况。这个里面要自己设计数据结构以便细分，例如{code: UsernameNotFound, message: 用户名不存在}

[hantsy]

Amazon 最新一代的 API 还没完成（没完全覆盖所有业务），上一代（现在通行）基于十几年的开发结果，不必细说。Http Status 处理，Github API 是典范，Github 返回的异常结果也有业务 code，但是仅针对 Httpstatus 表达不了的状态，作一个补充，现在 Github 也提供了新的 GraphQL 。

[hantsy]

@crclz 这个还不错。

尽可能利用 HttpStatus，比如用户注册，Email 已经存在，返回 Conflict 状态 ，这种表达更直接。POST 数据验证 Validation 失败，可以用 Unprocessable Entity，这些状态的字面意义才是对错误异常的说明起到真正辅助作用。

[hantsy]

@crclz https://www.restapitutorial.com/httpstatuscodes.html

[hantsy]

我不懂的是这些状态的字面意义这么清晰的情况下，完全抛弃不用，还要定义自己所谓的业务码，返回 200，把整个系统代码（前后端）搞成一锅粥。业务参考码我也会用一些，但会参考 Github，仅仅在一些通用错误下作补充说明，比如一些 400 太不清晰，其它的能用 HttpCode 一律不用业务码。

国内，这几年仅仅在上海做过两个创业项目，也是严格按我第一帖子的状态来写的，老板好像不会管你用什么方法解决，所以写成这样，公司老板是不应该背锅的。

[hantsy]

结帖。

[oneisall8955]

去年某段时间的周经贴

[ragnaroks]

草,只有我用自定义状态码?

[yaphets666]

统一返回 200 是最好了 你返回其他的状态码 有些状态码都到不了 js 里 直接被浏览器处理了 200 是前人实践出来的

[matenshi]

成功就 20x （不过不会像主楼说的那样区分）, 不成功看情况，40x，500 之类的（并返回错误信息）

[Airon]

成功 20x 错误 40x, 后端业务错误 500,具体业务错误 {code:, message: } 。基于工作环境的水平吧，大类错误码大家知道自带含义，那它就能起到辅助作用。

[cruii]

全部返回 200，结果后端出错封装一个自定义错误码。
这种就很让人不舒服，HTTP 规范告诉我请求成功了，结果后端告诉我请求出错了。

[binux]

@yaphets666 不会可以闭嘴

[akira]

@cruii 应该是指成功返回 200， 不成功的返回才使用别的

[yaphets666]

@binux 小伙子年轻吧 没遇到过运营商劫持非 200 返回的情况吧 你不知道别人为啥都 200 你最好别自己找自己的路 跟着别人走也许不太对 但绝对不至于出什么大事