这是一个创建于 2936 天前的主题，其中的信息可能已经有所发展或是发生改变。
我是写 API 的
写的好好的 REST API. 领导说要重构, 让所有的 HTTP Status 都返回 200. 这不是尴尬吗？
哎, 找了一堆国内的 API 作对比, 然后我扔给他 github 的 API 看. 但是没有起作用.
这可如何是好啊！！！
 |
101
jianghu521 OP @StevenTong 很好👍👍
|
 |
102
tidewind 2016-11-18 09:47:15 +08:00
@jianghu521 好吧，参考 1F
|
 |
103
vagasnail 2016-11-18 09:48:21 +08:00
支持 200 ，业务状态码不应该和网络状态码共用。业务和网络协议状态应该要分开。死搬硬套所谓标准是很没有意义的。
|
 |
104
barbery 2016-11-18 09:52:52 +08:00
我们也是用 http status code ，不过现在觉得不是很好，因为做一些 nginx log 的分析的时候，预期内的错误返回和预期外的错误返回 错误码根本分不开了~
|
 |
105
baiyi 2016-11-18 10:48:13 +08:00
强烈支持 rest,不建议硬肛领导
不太明白为什么这么多人使用 200 作为统一的返回状态 一个成功的请求,返回 204 No Content 不是比 { 'code' : 0}更加清晰吗? 一个失败的请求(缺少身份验证) 返回 401 Unauthorized {"error":"请提供 token"} 对比 返回 200 {"code":'xxxxxx'} 然后去文档中查询 xxx 所代表的含义 为什么一个在 success 回调函数+error 的回调函数就能处理的问题 要去解析下 json 再进行判断呢? |
|
106
jianghu521 OP @baiyi 是的 人家是领导啊！奈何啊
|
 |
107
sgissb1 2016-11-18 11:42:13 +08:00
小伙子，你就接受现实吧，我还遇到过狗屁不懂的人过来对我的工作指指点点的，然后嘴上吹着各种并行计算，分布式计算啥的，就没看到有些过代码或者真正对某一技术方案、架构了解过的。
不过，你这个或许有“特定”的使用场景。 |
 |
108
mhycy 2016-11-18 11:52:10 +08:00
支持领导
HTTP 状态码不能乱用 RESTful 只是一个推荐标准而已 实际项目依据需要可以完全不遵循，不是说遵循了这个标准就是个好的 API ，支持这一方案仅仅是个可选项而已 事实上，除了 API 内部接口，所有放到外网的 API 都应该遵循 HTTP 的默认准则，且是最小通用准则 200 301 302 304 401 402 403 404 500 例如以上几个状态码就是现行通用能标记请求状态的状态码 至于业务，老老实实返回绝对可靠的 JSON 结果，且用 200 表示结果合法。 （鉴于 200 也会存在数据不全的情况，服务端务必输出数据长度） 以增强程序的健壮性、可维护性与扩展能力。 |
 |
109
jerray 2016-11-18 13:38:36 +08:00
@yellowV2ex 微信的 API 设计非常分裂，文档写得也是东一句西一句，一堆人骂娘。
错误码当然不是完全靠 HTTP 的 Status Code 来判断，至少我的请求有问题的时候给我个 4XX ，服务器出问题的时候给我返回个 5XX ，返回统一结构的 JSON 来表示错误信息。这样在有些业务场景下，发现请求错误的时候可以完全不管 Body 内容。 |
 |
110
ppwangs 2016-11-18 13:46:09 +08:00
我已加入楼主战队。
只要有话语权，想改成什么样都行，但是要考虑实际的应用场景，就不得不屈服。 |
 |
111
mornlight 2016-11-18 13:53:57 +08:00
这个没必须要站队，两种方式都可以用，看设计者喜好。
|
|
112
jianghu521 OP @ppwangs 感谢 是的呢！
|
|
113
jianghu521 OP @mornlight 嗯 但是领导要求！就没有办法了！
|
 |
115
9hills 2016-11-18 14:11:55 +08:00
其实有些系统用 200+customcode 也挺好的，这样能区分出来到底是程序上的 error ，还是网络链接 or 服务器的 error
比如 HTTP 500 ，有可能是前端 nginx 有问题，也有可能是后端程序有个逻辑错误。如果用 custom code 就很好区别 |
 |
116
hanai 2016-11-18 14:37:38 +08:00
支持 200
|
 |
117
jason19659 2016-11-18 16:52:02 +08:00
restful 规范不是用 http 状态码表示的吗？
|
 |
118
ctftemp 2016-11-18 17:02:16 +08:00
那如果发生一个服务器异常，你就直接给客户端一个 500 ？不还是要包装成 200 和正常的 json 。
|
 |
119
enenaaa 2016-11-18 17:13:49 +08:00
我觉得这个 restful 标准不合理，应该改掉
|
 |
120
liyj144 2016-11-18 17:39:15 +08:00
返回到前端的接口都是 200 ，因为 js 中比较方便处理 json 类型的 body 内容，倒是把返回码放在 header 中处理起来会麻烦些。但是后端接口还是按 http 规定的返回码返回，这样一方面节省带宽和流量，另一方面方便后继的日志处理等，更何况后端一般 api 调用也就是先判断返回的 status 再判断返回内容的。
|
 |
121
hooych 2016-11-18 18:07:47 +08:00
|
|
122
jianghu521 OP @ctftemp http status 500 就表示服务器系统异常了
|
 |
124
lijy91 2016-11-18 18:56:14 +08:00 via iPhone  1
没必要纠结，全部 200 对于团队开发是比 Http Status Code 是更有优势的，对于那些连 Http 协议都不太了解的人，你可以省下很多时间去解释的。
慢慢你会发现，其实效率成本比这种完全标准化重要多了 |
 |
125
enjoyCoding 2019-01-24 11:12:06 +08:00
@murmur 我觉得挺好啊 要是让人知道了 500 这种错误 不是很 low 么
|
Select Language