前端根据什么来判定接口的请求状态?

完全根据http状态码吗? 成功有200 201 204等,失败就更多了。这个前端的判断是不是很复杂

《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
liyu001989
最佳答案

教程中使用的是 REST 风格,教程中已经解释了为什么要选择 REST,而不自己封装

file

通过body中自定义状态码判断,与使用 http 状态码没什么区别,只是一个是你自己定义的,一个是约定俗成的。

至于麻烦,常用的也就 这么几个:

  • 500 系列统一提示服务器异常;
  • 400 如果你前段代码没写错,应该不会遇到;
  • 401 统一逻辑处理,用户未登录或者token异常等;
  • 403 一般也是统一弹出提示;

剩下的常用的就是 200 201 204 422 ,你还觉得特别多?很麻烦?

5年前 评论
讨论数量: 4

我觉得应该跟前端一起讨论返回的格式。
有的时候会将错误信息封装在返回体中。
比如各大厂的短信api

5年前 评论

建议根据这几个方面去让前端判断

1、是否成功

2、返回码

3、返回信息

4、返回数据

实际应用中如果不需要请求数据,通过返回的状态码和返回信息前端基本就能完成判断。

5年前 评论

那种状态返回什么状态码 返回什么数据 这些都可以自己设计吧

5年前 评论
liyu001989

教程中使用的是 REST 风格,教程中已经解释了为什么要选择 REST,而不自己封装

file

通过body中自定义状态码判断,与使用 http 状态码没什么区别,只是一个是你自己定义的,一个是约定俗成的。

至于麻烦,常用的也就 这么几个:

  • 500 系列统一提示服务器异常;
  • 400 如果你前段代码没写错,应该不会遇到;
  • 401 统一逻辑处理,用户未登录或者token异常等;
  • 403 一般也是统一弹出提示;

剩下的常用的就是 200 201 204 422 ,你还觉得特别多?很麻烦?

5年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!