请假一个服务端 api 设计的问题，不同业务逻辑分支的跳转信息要怎样传递给前端？

[nonesuccess]

新接触 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 中设置特定的字段用来区分？

[Immortal]

没有大型 app 经验,就我之前做过的几个项目 api 经验来说(主要是 app,不是 web)
我这边一般定义三个字段,code,msg,data
1\ 错误码是我和前端自己定的一套逻辑码,并没有按照 http 协议的状态码来,因为这个我觉得从定义上来看是两码事
2\ 因为 1 的设计,你第 2 个问题就很好理解.比如登录密码错误返回错误码 1000,用户名不存在 1001 等等,这一套都是和客户端协商好的.一般服务端给的是 api 信息,客户端自己也需要定义一套同义的错误码,用来润色用户提示的文案,可能会显得麻烦.而你说的跳转逻辑,应该根据逻辑数据处理,也就是包含在 data 里,而不是根据错误码来
3\ 如果是单页应用,应该前端自己做路由控制和本地数据储存,后台做请求的身份校验(比如 session)

[xAx]

code 这个字段的定义不要 200、500 这样没可别识性。建议扩展一下。不过这不是重点。

前端提示信息，应当是前端的事，后端不要参与。
如后端返回性别值为 1,前端到底是展示男（女），还是先生（女士），后端管不着。错误提示信息同理。

前端页面跳转，应当是前端的事，后端不要参与。
如网页版要跳转到教师页面，手机 app 要跳转到教师 activity。api 后端不能管这事。不然这个后端 api 就不通用了。
后端应当通过鉴权来控制前端请求到底是否合法。

至于有新逻辑后是不是后端要改一遍，前端也要改一遍？
你想多了。有新逻辑，你后端要改那就改。前端关你 P 事。
如果，前后端都是你写？写个代码生成器，状态码与文本提示信息配置入库，直接代码生成器生成前后端的枚举类。

[luw2007]

1/2. 一般接口返回 code 既底层错误也有业务错误，不同业务有自己的号码段，前端可以简单的比较来判断业务是否正常，如果异常，在处理特定的 code 异常，其他情况则使用默认错误处理。接口 code 只是完成接口是否正常的功能，不应该混杂业务数据。
例如：code:
0 表示正常
xx 表示底层异常，比如参数错误，后端未知错误。这些错误应该在开发过程中解决掉。线上一般很难发生。前端需要做基本的处理。
1xx 开始表示具体业务错误。
客户端只需要先判断是否为 0，就知道业务是否正常了。不正常继续判断是否小于 10000，就知道是业务异常还是系统异常。一般业务异常就是枚举。需要客户端自行处理。

3. 后端开发 api 的时候，其实只是实现 mvc 中的 mc，你需要在登录接口返回用户权限类型。至于 mvc 中的 v 就是前端，判断权限，展示业务，跳转不同地址这些都是前端逻辑。后端只需要在 c 层做好权限判断。