新接触 app 开发领域,以前都是 SSH+jsp 一把梭。
设计服务端 api 的时候,统一设计了一个 code 属性,参照 http 状态码进行设计。由于就是预设的这么集中,所以就把这些码的定义、生成都封装到了框架里,不让每个业务逻辑自己控制。业务逻辑正常执行完,就给前端 200,发生了异常,大部分给 500,几种特定的异常给 404、403 等等。
另外,参考网上的经验,统一设置了一个 msg 字段。
做的过程中产生了疑惑,比如一个教务管理系统,用户登录功能,如果登录失败,则显示失败信息。如果登录成功,身份为教师,则进入教师 app 的功能首页,如果身份为管理员,则进入管理员 app 的功能首页。
那么:
1
Immortal 2018-03-12 15:31:34 +08:00
没有大型 app 经验,就我之前做过的几个项目 api 经验来说(主要是 app,不是 web)
我这边一般定义三个字段,code,msg,data 1\ 错误码是我和前端自己定的一套逻辑码,并没有按照 http 协议的状态码来,因为这个我觉得从定义上来看是两码事 2\ 因为 1 的设计,你第 2 个问题就很好理解.比如登录密码错误返回错误码 1000,用户名不存在 1001 等等,这一套都是和客户端协商好的.一般服务端给的是 api 信息,客户端自己也需要定义一套同义的错误码,用来润色用户提示的文案,可能会显得麻烦.而你说的跳转逻辑,应该根据逻辑数据处理,也就是包含在 data 里,而不是根据错误码来 3\ 如果是单页应用,应该前端自己做路由控制和本地数据储存,后台做请求的身份校验(比如 session) |
2
xAx 2018-03-12 15:46:56 +08:00
code 这个字段的定义不要 200、500 这样没可别识性。建议扩展一下。不过这不是重点。
前端提示信息,应当是前端的事,后端不要参与。 如后端返回性别值为 1,前端到底是展示男(女),还是先生(女士),后端管不着。错误提示信息同理。 前端页面跳转,应当是前端的事,后端不要参与。 如网页版要跳转到教师页面,手机 app 要跳转到教师 activity。api 后端不能管这事。不然这个后端 api 就不通用了。 后端应当通过鉴权来控制前端请求到底是否合法。 至于有新逻辑后是不是后端要改一遍,前端也要改一遍? 你想多了。有新逻辑,你后端要改那就改。前端关你 P 事。 如果,前后端都是你写?写个代码生成器,状态码与文本提示信息配置入库,直接代码生成器生成前后端的枚举类。 |
3
luw2007 2018-03-13 10:57:05 +08:00
1/2. 一般接口返回 code 既底层错误也有业务错误,不同业务有自己的号码段,前端可以简单的比较来判断业务是否正常,如果异常,在处理特定的 code 异常,其他情况则使用默认错误处理。接口 code 只是完成接口是否正常的功能,不应该混杂业务数据。
例如:code: 0 表示正常 xx 表示底层异常,比如参数错误,后端未知错误。这些错误应该在开发过程中解决掉。线上一般很难发生。前端需要做基本的处理。 1xx 开始表示具体业务错误。 客户端只需要先判断是否为 0,就知道业务是否正常了。不正常继续判断是否小于 10000,就知道是业务异常还是系统异常。一般业务异常就是枚举。需要客户端自行处理。 3. 后端开发 api 的时候,其实只是实现 mvc 中的 mc,你需要在登录接口返回用户权限类型。至于 mvc 中的 v 就是前端,判断权限,展示业务,跳转不同地址这些都是前端逻辑。后端只需要在 c 层做好权限判断。 |