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

[pwli]

如果要上监控和重试的话，失败请求不建议返回 200

[hantsy]

@xlinux https://www.restapitutorial.com/httpstatuscodes.html 这个页面标星基本都是最常用的。4xx 系列之前项目还用到
422 Unprocessable Entity (WebDAV) 输入验证异常用上了这个。
402 Payment Required

405,406，415 这种基本都是非法调用，框架会提示你。

[ChanKc]

@pwli 是的，我最近打算上一些日志分析就发现。
如果一些错误用 400，直接打 access_log 里面，然后用标准的 access_log 分析工具分析就能看到一些数据
要是都是 200，还要造一堆轮子

[ChanKc]

@qdzzyb 我作为前端，很不喜欢统一 200
如果用 axios，我要自己封装 Promise 异常
如果用 service worker 做缓存，我 fetch 完了还要把 body 用 json()拿出来判断一下才能决定要不要缓存

[qdzzyb]

@ChanKc #24 其实我也不喜欢都返回 200 尽量能用状态码就用状态码

[hantsy]

@ChanKc 除了 ELK, EFK 之类的，可以看看现在的云服务，PagerDuty, DataDog 之类。

[qdzzyb]

@hantsy #17 前面开发的大佬用了这一套，前端也都封装好了

[bigWolf999]

还有一个问题，数据量大且结构复杂的请求数据是否只能将 GET 改为 POST 呢?

[labulaka521]

习惯就好，上面那个说别人 SB 才是个大 SB

[passerbytiny]

不想细分就 200，想细分就 20*，*具体是哪个前面有人回复过了。

成功统一 200 （ OK ），错误统一 500 （服务器内部错误），也是符合 RESTful 的，只不过 500 太多显得服务器很无能。


至于“全部 200”这样的回复，劝一句楼主，不要跟闭眼抄作业的人玩。

[happypy1]

如果你的 GET 是来搜索的话，即使你没有找到数据，你应该返回 200 OK，因为 200 意味着你的搜索请求，服务器执行成功了。而且像这种搜索 endpoint 的话，你应该是返回一个空的数组，如果没有找到资源的话。

但是如果你的 GET 是要拿一个具体的资源的话，比方说你知道 ID：GET /custoemrs/1，后端要是没有找到，就应该返回 404 。否则就返回 200 。

202 一般是用于表示后台已经接受了你的数据，但是还没有处理完成。参考一下[MDN]( https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/202)

如果你只是简单的创建或者更新数据的话，200 即可。

[xuanbg]

@passerbytiny 全部 200 的意思是只要服务能够正常访问就返回 200 。http 的状态和业务的错误分开。

[daimubai]

我们项目：
请求成功统一 200
客户端错误统一 400
服务端错误统一 500
系统异常错误—999

[hantsy]

@labulaka521 神经病

[renmu123]

v2 周经贴

[hantsy]

@bigWolf999 有些 API 有一个专有的 _search endpoint，比如 /products/_search，可以看看 MS API 设计（被 REST 之父喷过），还包括各种比较，逻辑操作等，太复杂了，query params 表达不了，这种 POST 方便。

[hantsy]

@qdzzyb 后端 java Spring，我之前也见过这种神封装，好好的 ResponseEntity 带个套，所有的 Controller，所有方法返回用一个 Util 套一下。

[labulaka521]

@hantsy nmsl

[hantsy]

@labulaka521 就你这样，我真替你父母感到悲哀。
在工作中，你就是我说那种人，狗屁正事做不了，借口比谁都多的巨婴，整个公司估计也没人待见你。

[jones2000]

@hantsy “不同的路径下 404 的意义已经将不同的 Resource 区分的很清楚，只有 SB 才用 200 返回一切数据” 你这种方式我没看到过，太高级了， 我还不会用，特别是如何把 sql 的执行错误的详细信息如何返回给前端然后提示客户。

数据库执行错误就几十种， 主键冲突， 表不存在，账号没有写权限等等，还要具体错误信息。

像以下的详细的错误应该如何通过你的 404 返回给前端
1. “ALTER TABLE `xxxx_db`.`STOCK2604` DROP PRIMARY KEY
Can't DROP 'PRIMARY'; check that column/key exists”

2. “ALTER TABLE`xxxx_db`.`STOCK2604`ADD PRIMARY KEY(`ORGID`,`SECCODE`,`ENDDATE`,`F001V`,`F004V`)
Specified key was too long; max key length is 767 bytes”

3. “SELECT CAST(CONV(HEX(MAX(`XDBMASK`)),16,10)AS UNSIGNED),CAST(CONV(HEX(MIN(`XDBMASK`)),16,10)AS UNSIGNED)
FROM`xxxxxx` WHERE CAST(CONV(HEX(`XDBMASK`),16,10)>0
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 2”