还能不能好好的写 API 了

[jianghu521]

我是写 API 的

写的好好的 REST API. 领导说要重构, 让所有的 HTTP Status 都返回 200. 这不是尴尬吗？

哎, 找了一堆国内的 API 作对比, 然后我扔给他 github 的 API 看. 但是没有起作用.

这可如何是好啊！！！

[jianghu521]

@StevenTong 很好👍👍

[tidewind]

@jianghu521 好吧，参考 1F

[vagasnail]

支持 200 ，业务状态码不应该和网络状态码共用。业务和网络协议状态应该要分开。死搬硬套所谓标准是很没有意义的。

[barbery]

我们也是用 http status code ，不过现在觉得不是很好，因为做一些 nginx log 的分析的时候，预期内的错误返回和预期外的错误返回 错误码根本分不开了~

[baiyi]

强烈支持 rest,不建议硬肛领导

不太明白为什么这么多人使用 200 作为统一的返回状态

一个成功的请求,返回 204 No Content 不是比 { 'code' : 0}更加清晰吗?

一个失败的请求(缺少身份验证) 返回 401 Unauthorized {"error":"请提供 token"} 对比 返回 200 {"code":'xxxxxx'} 然后去文档中查询 xxx 所代表的含义

为什么一个在 success 回调函数+error 的回调函数就能处理的问题 要去解析下 json 再进行判断呢?

[jianghu521]

@baiyi 是的 人家是领导啊！奈何啊

[sgissb1]

小伙子，你就接受现实吧，我还遇到过狗屁不懂的人过来对我的工作指指点点的，然后嘴上吹着各种并行计算，分布式计算啥的，就没看到有些过代码或者真正对某一技术方案、架构了解过的。

不过，你这个或许有“特定”的使用场景。

[mhycy]

支持领导

HTTP 状态码不能乱用
RESTful 只是一个推荐标准而已
实际项目依据需要可以完全不遵循，不是说遵循了这个标准就是个好的 API ，支持这一方案仅仅是个可选项而已
事实上，除了 API 内部接口，所有放到外网的 API 都应该遵循 HTTP 的默认准则，且是最小通用准则
200 301 302 304 401 402 403 404 500
例如以上几个状态码就是现行通用能标记请求状态的状态码

至于业务，老老实实返回绝对可靠的 JSON 结果，且用 200 表示结果合法。
（鉴于 200 也会存在数据不全的情况，服务端务必输出数据长度）
以增强程序的健壮性、可维护性与扩展能力。

[jerray]

@yellowV2ex 微信的 API 设计非常分裂，文档写得也是东一句西一句，一堆人骂娘。
错误码当然不是完全靠 HTTP 的 Status Code 来判断，至少我的请求有问题的时候给我个 4XX ，服务器出问题的时候给我返回个 5XX ，返回统一结构的 JSON 来表示错误信息。这样在有些业务场景下，发现请求错误的时候可以完全不管 Body 内容。

[ppwangs]

我已加入楼主战队。
只要有话语权，想改成什么样都行，但是要考虑实际的应用场景，就不得不屈服。

[mornlight]

这个没必须要站队，两种方式都可以用，看设计者喜好。

[jianghu521]

@ppwangs 感谢 是的呢！

[jianghu521]

@mornlight 嗯 但是领导要求！就没有办法了！

[pljhonglu]

@iyangyuan 这种理解可以~

[9hills]

其实有些系统用 200+customcode 也挺好的，这样能区分出来到底是程序上的 error ，还是网络链接 or 服务器的 error

比如 HTTP 500 ，有可能是前端 nginx 有问题，也有可能是后端程序有个逻辑错误。如果用 custom code 就很好区别

[hanai]

支持 200

[jason19659]

restful 规范不是用 http 状态码表示的吗？

[ctftemp]

那如果发生一个服务器异常，你就直接给客户端一个 500 ？不还是要包装成 200 和正常的 json 。

[enenaaa]

我觉得这个 restful 标准不合理，应该改掉

[liyj144]

返回到前端的接口都是 200 ，因为 js 中比较方便处理 json 类型的 body 内容，倒是把返回码放在 header 中处理起来会麻烦些。但是后端接口还是按 http 规定的返回码返回，这样一方面节省带宽和流量，另一方面方便后继的日志处理等，更何况后端一般 api 调用也就是先判断返回的 status 再判断返回内容的。

[hooych]

@Ouyangan
我倒是支持都返回 200 , 响应体中 data ,code,msg . code 用来做校验字段 ,msg 做提示信息
+1

[jianghu521]

@ctftemp http status 500 就表示服务器系统异常了

[Ouyangan]

@ctftemp 对的 ,一般要根据请求类型返回不同类型的响应 .做一下统一错误处理.

[lijy91]

没必要纠结，全部 200 对于团队开发是比 Http Status Code 是更有优势的，对于那些连 Http 协议都不太了解的人，你可以省下很多时间去解释的。

慢慢你会发现，其实效率成本比这种完全标准化重要多了

[enjoyCoding]

@murmur 我觉得挺好啊 要是让人知道了 500 这种错误 不是很 low 么