喷了一个没写过接口的后台服务器开发人员的后果

[tyo]

刚去一个公司，喷了一个没写过接口的后台开发人员，结果搞的自己也很 Lower 。喷的原因很简单，接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名。 现在决心不说话，避免被说成是心态不好，大惊小怪。好无语。求安慰。

重要的不是能力，而是和谐的团队氛围，你认同这句话吗？

[ihuotui]

如果用 HTTP 状态码 ，就是把 协议变为两个，一个 HTTP 状态码 一个 json ，复杂度增加。
然后用 HTTP 状态码 越具体，越不能拓展，就像泛型一下才好拓展，越抽象越好拓展。

[tairan2006]

换公司，下一题

[sobigfish]

接口地址写错，参数写错，拖延整个项目进度，压缩自己的开发时间，随意更改字段名....
话说 API 没文档？这个锅应该 pm 背吧

[simo]

唉，和和气气，坐办公室油子，谁都会， but ，真不容易做到。

[simo]

@mikulch 道理通，说的很对。
多次出现以下的类似情况，你（角色只是一个前端或者后端开发人员）会如何做？（真心求解）
例：你是前端开发，编辑用户接口，后端接口返回项里有 “密码” 这一项

[noli]

@mhycy 但是 4XX 错误肯定不是环境的问题啊，更进一步，如果不是协议上的问题而是例如连接问题，你扔个 200 过去也不能保证客户端能正确接收

[jarlyyn]

慢着，楼上那些讨论 api 的。

为什么 4xx 错误会和 json 的状态码有关系？

4xx 错误不是对应的是 200 么？

就算 4xx 错误，典型如 422,也要返回具体的错误数据啊？

跑 2xx,3xx,4xx,5xx 只是为了让缓存服务器和客户端更好的处理啊。

[mhycy]

@noli 要考虑到网络上各种奇葩的中间设备会有的奇葩规则，开发时还是要看 API 用在哪个地方
如果是内网，不经过啥奇葩的中间设备的话， HTTP 状态码直接表示资源状态也是可以的。
但是在外网，考虑到各种奇葩的中间设备有可能存在的情况下， 200 是个更稳妥的选择。

[dantangfan]

一个吐槽贴，被强行转成了状态吗的月经贴。

[noli]

@mhycy 考虑的设备更多应用涉及的规模越大才更应该好好地使用 Http 状态码，毕竟 http 状态码是 RFC 上定义的而你自己定义的状态码只是你的什么鬼文档里定义的。 试图在一个庞大系统中的单点解决所有问题，这是想得太多，优化太早。

[hcymk2]

大厂的.
https://developers.google.com/drive/v3/web/handle-errors

[hcymk2]

另一个大厂的
http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html

[mhycy]

@noli
考虑到项目的规模才应该使用更通用的实现，即便这个实现在某些时候看上去并不“优雅”
为了“优雅”而对问题视而不见，这不是一个合格的工程师应有的态度

[noli]

@mhycy 你说的原则我很同意。但我觉得 Http Status 比 Json 或者别的什么格式表示的 status 更“通用”，更简单更暴力更少歧义。任何一个合格 Http Client 都肯定能解析得出这个 http status 。

[mhycy]

@noli
当你遇上一个没法更改的机房设备的时候你就不会这么说了。。
HTTP 状态码来表示资源状态那当然是很好的做法
但是当网络路径中存在一些奇葩的设备带有奇葩规则的时候这就不是一个合适的选择了

这也是我在上文中强调“外网”的原因。

[jingniao]

手上的项目其实挺想用成 rest ful 标准的的状态码的。
但没用，前端没配合，可能在他们眼里，这是给他们增加工作量

[noli]

@mhycy 你说的不就是 明文 HTTP 被中间设备篡改内容 而已嘛。担心这个，上 HTTPS 才是正途，而不是在 API 上面搞什么自主创新，开发者的时间重新发明轮子来处理这个问题根本就是浪费时间。

[mhycy]

@noli HTTPS 也可以劫持，别忽略例外情况

[noli]

@mhycy 我知道在使用劣质 CA 签发的证书的情况下 HTTPS 可以等于没有，但排除这种情况之后， HTTPS 是无法劫持的。即使是存在劣质 CA 这样情况，因为存在 HTTPS 劫持的缘故多花时间重新做一套本来解决 HTTP Status code 就足以解决的问题，依然是不值得的。并且，如果连 HTTPS 劫持都做得出来，你觉得我们讨论在 JSON 里面放 400 还是用 HTTP Status 来放 400 什么的，这些还有意义吗？

[mhycy]

@noli
其实我想说的情况是公司内部自签发证书在网关拦截请求进行监控的情况下 HTTPS 是不可靠的。

考虑到运维以及可能出现的各种网络问题引起的状态码异常（客户端劫持）
我是认为 Web 环境中不适宜用 HTTP 状态码来代表业务状态，软件的 API 倒是可以用这种形式来实现。
但是为了明确区分应用层故障还是网络异常， HTTP 状态码保持 200 在某些时候是更合适的选择。