为什么后端开发都喜欢自己定义 responseCode? HTTP 状态码不够用吗?

2020-05-29 14:10:45 +08:00
 watanuki

所有请求都返回 200,然后自己定义 responseCode, 好像很多大厂的后端接口都是在这样做的,这样做有什么好处? 现在后端开发是不是已经有了关于 responseCode 的统一标准?还是一个公司一套标准? 如果没有统一标准,大家在开发个人的后端项目时也会用 responseCode 吗?

26267 次点击
所在节点    程序员
216 条回复
Conda
2020-05-29 14:16:26 +08:00
老的开发模式大概是 code 、data 、message 这种格式,后端会重新定义返回的业务状态码,而不是依赖于 Http Code,而在 resetful 风格则没有这个业务 code 一说了。当然所有请求返回 200 也不对,400 500 一类的还是该怎么返回就怎么返回
wangyanrui
2020-05-29 14:19:56 +08:00
http 状态码不够用,所以自定义~
cheng6563
2020-05-29 14:20:49 +08:00
业务稍复杂点的系统。完全按 resetful 来就是自己找镣铐,http 那几个状态码根本就不够用。
kanepan19
2020-05-29 14:20:56 +08:00
业务 code 和 通信 code 分开 没毛病
littleylv
2020-05-29 14:22:31 +08:00
你这里说的 responseCode 不是用来代替 HTTP 状态码的。是两码事。

比如后端验证后发现,某个必填字段你没填。 返回给前端的 http 状态码仍然是 200,然后自定义一套{'code':10001, 'msg': ‘xx 字段必填’}。这不是很正常的操作吗?不然你觉得这种情况要返回什么 http 状态码
Oktfolio
2020-05-29 14:23:48 +08:00
```
public class ResultEntity {
private Integer code;
private String message;
private Object data;
@JsonIgnore
private HttpStatus status;
@JsonFormat(pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'")
private LocalDateTime datetime;
}
```

个人项目的话。GET 以外的方法结果为 20x 的时候,除特殊情况什么都不返回,GET 只返回内容,没有上面的封装。有错误的时候才上面封装的内容。status 是方便在 service 层返回状态给 controller 用的,实际是会以 http 状态码返回给前端。会用到 GET POST DELETE PUT PATCH 五种 Method 。
```
public class ResultEntity implements Serializable {

private boolean success;
private String errorMsg;
private int errorCode;
private String errorLevel;
private Object content;
}

public class PageResultEntity implements Serializable {

private int currentPage;
private int pageSize;
private long totalCount;
private int pages;
private List<Object> data;

}
```
工作嘛,全用 GET POST,全返回 200,然后就是上面定义的内容了。
DsuineGP
2020-05-29 14:24:52 +08:00
restful+HTTP 状态码足够通用,但是不够符合实际的业务需求.
比如我这边有一个需要批量查询 100 条数据的接口需要实现(因为有性能要求,必须支持单请求批量查询),实际运行中可能其中 99 条成功查询到了,1 条由于某种原因失败了,那么从 api 接口上如何设计呢?
是 POST 请求然后响应 200 吗?
实际上个人这种设计不符合 restful 的语义,也不完全符合响应码 200 的语义.
最终还是要落到自定义响应码上.
leo108
2020-05-29 14:29:55 +08:00
sunny352787
2020-05-29 14:34:31 +08:00
所以你们真的没听说过运营商劫持的情况吗?非 200 返回码给你劫持掉,导致某个地区用户投诉量剧增...
Oktfolio
2020-05-29 14:35:39 +08:00
@Oktfolio 但是我这样就需要兼顾 HTTP Status Code 和自定义 Code 。
Oktfolio
2020-05-29 14:37:30 +08:00
@sunny352787 以前的事情啦,现在应该没有了。
guyeu
2020-05-29 14:38:13 +08:00
HTTP 的 status code 是可以扩展的。。。个人认为通过通过扩展 status_code 来实现更多的响应码是一种比较好的实践。
krixaar
2020-05-29 14:38:35 +08:00
之前不是有帖子讨论过这事儿了么,就是没必要死扣标准,其中一个想法是,http 的 response code 只代表接口自己的状态,然后返回的 code 和 message 代表业务实际的状态。
比如 http 200 说明接口好的,http 400 说明你接口写错了,http 500 说明接口挂了。
返回的 code 和 message 再告诉你具体什么情况。
sunny352787
2020-05-29 14:38:36 +08:00
@Oktfolio 并不是所有用户都在北上广深啊...
wangyzj
2020-05-29 14:42:25 +08:00
http code 只是 http 访问的问题
return code 是接口返回的问题,不代表接口有错
yongjing
2020-05-29 14:43:21 +08:00
不够
unicloud
2020-05-29 14:44:53 +08:00
绝对不够!
gushidefengzheng
2020-05-29 14:45:45 +08:00
当然不一样,HTTP 状态码表示服务器服务状态,只能表示几种基本状态。
而 Response Code 是业务状态码,一套系统下来可能与上百了状态码,你可以看一下微信公众号开发文档里错误码的定义有多少个,每个状态码表示不同的问题,要的是能够精准定位。
hantsy
2020-05-29 14:49:10 +08:00
参考 github api 设计就行了,Http Status 没有必要去扩展,Error API 或者使用 Problem API 信息包含详细的描述。

https://docs.spring.io/spring-hateoas/docs/current/api/index.html
ArtIsPatrick
2020-05-29 14:54:03 +08:00
http 状态码从名字就可以看出来指的是 http 请求的状态,不是业务的状态。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/676678

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX