了解下现在接口返回都是什么形式, 要不要提示文本?

[onikage]

http, json. 以登录接口为例, 两种方案:

1. 返回{"code":0} 代表成功, {"code":1} 代表用户名密码不匹配. 前端页面自己根据 code 显示不同提示文案.
2. 返回{"code":0,"msg":"登录成功"}, {"code":1, "msg":"用户名密码不匹配"}, 页面上直接显示 msg 属性的文本. 我个人认为第二种非常啰嗦, 一个 code 足以说明问题, 但是好像不少人都习惯第二种.

[makun123]

必须第二种好，使用起来也更灵活些，一个 code 可以对应多个 msg，我还有场景用到，一个 code 对应的 msg 提示中拼接一些业务处理后的提示参数，第二种直接返回了，第一种还得和 FE 特殊约定下

[makun123]

还有题外问下楼主已经 40+了么

[FallenTy]

第二种后端也能做国际化，功能实现都一样，这种就是少数服从多数了。

[KyrieJoshua]

@onikage 10L
如果抱着图省事的心态让前端做，以后前端就不理你了。。

[zgray]

有种场景必须用 2，而不能用 1 。

当后端有个原来预想外的逻辑要额外增加错误提示，但是发布前端已经来不及（前端可能是 APP，或者是利用 electron 之类的客户端方案），必须后端先修复，这个时候前端如果是用 msg 提示，那么后端是可以立刻修复后发布。而不给 msg 只用 code，前端这时候只能报“内部错误”这样的提示了。

[ily433664]

肯定是第二种，就算你想让前端自己控制提示语句，第二种也可以兼容

[queuey]

第一种很傻，
code 是通用的，如果按照第一种来的话，付款失败可能有几十种原因，判断 code 给几十个 前端自己处理？

[Hslacker]

第二种，前端不用写一堆枚举

[ytmsdy]

第二种吧！这样还能悄咪咪的加入一些其他的提示脚本，这样前端就不需要重新发布。
要不然新增一个提示信息，前端需要修改，后端也需要修改。

[zxCoder]

第二种，只用修改一端

[aguesuka]

当然要, 后者是前者的超集, 第一种方案能实现的第二种都能实现. 第一种情况需要维护一个超级大的枚举, 非常反设计.

[balabalaguguji]

刚好有写一个响应参数的教程 https://easydoc.net/posts/response-data-design/

[libook]

看需求。

如果前端需要对文本进行风控或限制的话，第一种方案比较合适。
如果希望能快速调整文本的话，第二种比较合适。

[liuhuihao]

当然是第二种
常见的场景就是 APP，产品可能要修改一个小小的错误文案，使用第一种的话，就要给所有用户推送更新才行，第二种后端直接修改即可。

[sytnishizuiai]

我一开始想用 1，但是 msg 中文也写了，顺带的，后来慢慢变成 2 了，code 自己写多了烦，还要写文档，前端找，还不如用 2 的方式，我现在 code 也不写多了，除非需要前端去判断的才额外写个 code 。

[onikage]

@netwjx 作为后端, 我认为的核心就是少一部分工作量以及对应的 bug.

[onikage]

@queuey 你是在说微信的这种接口很傻吗?
https://developers.weixin.qq.com/doc/offiaccount/Getting_Started/Global_Return_Code.html

[waytoshine]

你的观点，只能说你目前没做过什么稍微大点的系统的开发

[kekxv]

前端：？要不要我把后端接口也做了？🐶

[onikage]

@waytoshine 什么叫大?