新接触 app 开发领域,以前都是 SSH+jsp 一把梭。
设计服务端 api 的时候,统一设计了一个 code 属性,参照 http 状态码进行设计。由于就是预设的这么集中,所以就把这些码的定义、生成都封装到了框架里,不让每个业务逻辑自己控制。业务逻辑正常执行完,就给前端 200,发生了异常,大部分给 500,几种特定的异常给 404、403 等等。
另外,参考网上的经验,统一设置了一个 msg 字段。
做的过程中产生了疑惑,比如一个教务管理系统,用户登录功能,如果登录失败,则显示失败信息。如果登录成功,身份为教师,则进入教师 app 的功能首页,如果身份为管理员,则进入管理员 app 的功能首页。
那么:
- 后端判断登录失败时,给前端返回一个 code 500,是否合适?
- 后端判断登录失败,根据不同情况,“用户名密码不匹配”、“用户已过期”这类的错误提示信息,是后台生成后打给前端,还是给前端不同的 code,让前端去自己判断?如果放在后端,那么相当于后端要处理很多界面上的细节。如果放在前端,那后端的每个逻辑都要设计很多个 code 值,不利于封装。如果 code 值统一写 500,用 msg 给前端传错误信息,那只是显示错误信息的需求还好,如果有后续的不同跳转逻辑,前端也难以通过一个非枚举性质的字符串做后续的处理
- 不同角色的人,跳转到不同的功能首页,在做 jsp 的时候,mvc 框架负责路由到一个 jsp 资源。在 app 这种前后端分离的框架应该怎样做?是统一一个 code 字段区分,还是根据每个业务的不同,在返回的 json 中设置特定的字段用来区分?