API 不管操作成功还是失败都返回 200 状态码，自己在返回结果里又定义一个表示是否成功的属性是从哪里传开的坏习惯？

@edis0n0 httpClient ，okhttp ，以及 springboot 里常用的 feign ，当然可以写回调处理非 200

这些不是重点，重点是用 http code 很难满足在异构系统下完成比较通用的业务表达，况且团队间能力参差不齐，制定统一的消息结构规范避免大家在不同传输协议上做过多纠结

@eason1874 什么年代了，还运维打业务日志。。。ELK 搞一套业务的，一套运维的不香吗？

但凡对 OSI 七层模型有一点了解，也不至于会纠结这个问题。所以基本上也能快速分辨出哪些是科班出身的人。

参考微信支付 v3 API ，restful：
https://pay.weixin.qq.com/wiki/doc/apiv3_partner/apis/chapter9_1_1.shtml

@shakoon #63 照你这么说 stripe twitter 的程序员全都不是科班出身的吗

你猜它为什么叫 http status code 而不叫 api status code 呢？
看着两个东西长得差不多就搁这硬套，硬套不要紧，还跑出来秀智商。

@edis0n0 你现在没有完全的论据证明 stripe twitter 完全是你想的那样的。。。有渠道的话建议你先问问 stripe twitter 内部真正的程序猿再说。。。。

别人的应用代码你都要专门批判一番, 恶臭爹味了

我在做后端新项目时候，也在想该用 200 包所有自定义的东西呢，还是用 restful 风格来做呢，最后选择用了 restful ，事实证明，光用 restful 远远不够判断业务逻辑的情况，我最后在 2xx 的所有请求里面，自定义的一套状态状态码😂

全用 200 不是没啥经验就是懒，用了 http code 就不能用自己业务状态码吗？懒是可以理解，鼓吹就算了，大家还是多遵守规范的好

http 套 rpc 是很好的选择，看 grpc 多流行，没必要片面的否定。

说起这个最近调电信的 5G 平台 api ，结果电信硬是自己编了个 799 的 http 状态码，搞得我封装的好好的代码为了它单独加了一坨处理，真服了

http 状态是传输层状态，反映网络问题，谁知道是不是中间商给拦截了还是用户路由器问题？如果是内部 rpc 调用，我觉得这么搞没什么问题，但也要看状态码能否适应业务复杂度。

http status code 是与业务无关的，业务相关的 status 还是需要通过报文返回，所以我们讨论的其实是业务无关给状态应该如何返回。其实用啥都可以，但是如果用 http status code 的话会增加一些沟通成本和程序员的心智负担，因为要学习和沟通两套 code 。我觉得能 All in one 都尽量 all in one ，看看现在企业的各种平台不都是能集成在一起的都集成在一起了，多转个圈就多了一分成本。

而且现在有些公司用 http 是对外的 web 接口，有些公司则直接用 http 作为 rpc ，后者如果为了以后升级方便，应该尽量不要依赖 http status code ，http 仅作为传输层使用。

https://tanronggui.xyz/t/808610 之前也讨论这个问题

什么 http 原教旨主义

使用 JMeter 进行压测的时候，全是 200 成功，其实打开后发现大多数多数其实是错的。

争来争去，谁也说服不了另一方，我觉得只要有规范约定清楚，用啥都行，个人更倾向于 200+post+json+code

发现 op 非常偏激。twitter 这些国外平台用的一定是对的。国内不是这么用的一定是错了。

200 是状态码，不是结果码……连接是正常返回就可以叫做状态 200 ，至于结果，那可复杂多了