2023年8月1日发(作者：)
HTTP码是200，响应体的code是500，什么⿁？前⾔有⼈突然问了我这么⼀个问题，说后端传过来的数据，HTTP状态码（以下简称HTTP码）是200，响应体的code是500，这种操作怎么理解？到底是200还是500？HTTP码是200响应体返回code是500我本以为，这叫啥问题，结果。。憋了半天我竟⼀时不知道怎么回答。。今天彻底搞清楚！RESTfulRESTful是想尽办法利⽤现有的HTTP协议的各个“成员”，⽐如Method就把PUT、PATCH、DELETE这种⽅法都⽤上了，那么HTTP码这么好⽤的东西是⼀定是要⽤的。⽽且，RESTful根本就不允许你在响应体⾥写{code: 200}这种⿁。项⽬现状回到项⽬现状中，在请求体⾥写{code: 200}⼏乎成了某些⼈眼⾥的业界规范了啊！HTTP码⽆脑200啊！这咋解释？！其实很好解释，这就是半瓶⼦咣当的程序员对于HTTP码理解错误，前端对后端说⼀句：“你要给我返回状态码啊”，后端就屁颠屁颠的把码放到请求体⾥了，前端看到后，⼼想：“⼜不是不能⽤，算了，反正绝⼤多数情况下都是200”。所以，到今天，搞得这成了业界标准⼀样。⽽且⼀些框架本⾝就使⽤HTTP码200、code 500来报错。从业界来说，结果成了：1. 脑⼦⽐较清醒的程序员，⽤HTTP码表达状态，⽤axios拦截器对各种HTTP码做了处理。2. 脑⼦不清醒的程序员，⽤code表达状态，axios拦截这个code，当然，最后肯定能跑通。但是，这显然是不规范的。常⽤状态码都有什么？建议不要超出这⼏个，这⼏个⾜够⽤。200请求成功201创建成功 专门⽤于创建新的记录的时候301永久重定向 ⽹址永久变更成另外⼀个⽹址302临时重定向 ⽹址临时变更成另外⼀个⽹址400⽆效的请求 请求的⽹址⽆效等401没有登录 需要登录才能访问403没有权限 虽然登陆了，但是没有权限404请求资源不存在 请求的东西不存在，⽐如某个⼈的信息500服务器端错误 服务器端发⽣了错误业界⼤公司，谁在⽤{code: 200}？⼀个不存在的公司，FaceBook，就在⽤{code: 200}。⾕歌等公司在⽤状态码200。再⽐如现在有个流⾏的java+vue后台系统，若依，官⽅演⽰的code我们看⼀下，它不是{code: 200}：P码不是200的话，能返回响应体么？当然能，包括HTTP 404错误，都能返回你想要的JSON格式的响应体。只在HTTP码写，前端能精准捕获吗？这个问题才是核⼼关键！你在HTTP码写的飞起，但前端捕获不了，不也是⽩扯么？我们测⼀下：原⽣Fetch成功时：服务器返回404时：跨域，但⽬标服务器⽆效时：ery这种⽅法是可以精确捕获各个错误代码的：$.ajax({ dataType: "json", url: '', statusCode: { 200: function(err) { (err); }, 404: function(err) { (err); } },});成功时：返回JSON本⾝。404出错时：os利⽤响应拦截器拦截⼀下：( function (response) {// 对响应数据做点什么 return response; }, function (err) { (se); });成功时：404出错时，se打印：结论市⾯上主流的ajax库和原⽣Fetch都⽀持捕获404，⽽且都是存放在。其他的HTTP码也都是⼀样的道理，就不多说了。所以，有什么理由不使⽤HTTP码呢？？HTTP码到底怎么定？1. 成功的状态码⼀定是200，就⾏了。2. 关于失败的状态码，我专门说⼀下，其实并没有什么⼀定之规，只要保证：如果使⽤常见的HTTP状态码，⼀定要符合通常理解的规范；如果使⽤了⾃定义的状态码，⽐如1000以上的状态码，那就团队⾃⼰定就好了，定了就要遵守，别经常变来变去。3.
msg只是在弹窗⾥显⽰，不要拿msg当做出错的判定依据，必须只拿HTTP码当做依据。最后⼀个问题，响应体应该怎么写？先说GET的响应体{ msg: null, rows: [...], total: 14 }1. 不要写code，不要写code，不要写code！2. msg在200前提下就null，因为成功前提下没有必要弹窗提⽰，除⾮极少数场合真的需要弹窗提⽰，不在200前提下可以写明到底什么出了错。msg的内容就是给中国⽤户看的可阅读的提⽰，会由前端组件放到提⽰框⾥，因此，绝对不要写“success”或者“err”这种⿁！！3. rows也可以叫list，强调的是数组解构，空数组则返回[]。不是数组的话，也可以叫result，result可以是基本类型也可以是⼀个对象。不要使⽤data作为字段，因为data意义不明确。尽管现在业界普遍使⽤data，但是加上axios封装响应体也会加上data，结果会写成这种取值，很容易脑⼦短路。4. 不要字段套字段，应尽量扁平。5. total是可选属性，表⽰数组资源总数。还可以加其他的字段传递别的数据。6. 在HTTP码不是2开头的情况下，除了msg，不要有其他属性。然后说POST、PUT、DELETE的响应体{ msg: '修改成功'}1. 如果200前提下，就返回msg就可以了，修改就是“修改成功”，删除就是“删除成功”，新增就是“新增成功”、“创建成功”等等的。2. 总会有失败的可能，⽐如删除失败，资源被别⼈先删了，你再删就是删除失败，这时候HTTP状态码不应是200（具体是多少看你们团队的规范），msg应当是删除失败：资源已被删除这类提⽰。其他的，⽐如“⽀付成功”和“⽀付失败”，⼀般来讲，成功，则页⾯路由会变化，进⼊下⼀个环节，失败，则原地弹出提⽰，可能要求⽤户换⼀种⽀付⽅式或者放弃⽀付，因此，失败的HTTP状态码不应是200（具体是多少也看你团队的规范），msg应当是⽀付失败：卡余额不⾜这类的话。
2023年8月1日发(作者：)
HTTP码是200，响应体的code是500，什么⿁？前⾔有⼈突然问了我这么⼀个问题，说后端传过来的数据，HTTP状态码（以下简称HTTP码）是200，响应体的code是500，这种操作怎么理解？到底是200还是500？HTTP码是200响应体返回code是500我本以为，这叫啥问题，结果。。憋了半天我竟⼀时不知道怎么回答。。今天彻底搞清楚！RESTfulRESTful是想尽办法利⽤现有的HTTP协议的各个“成员”，⽐如Method就把PUT、PATCH、DELETE这种⽅法都⽤上了，那么HTTP码这么好⽤的东西是⼀定是要⽤的。⽽且，RESTful根本就不允许你在响应体⾥写{code: 200}这种⿁。项⽬现状回到项⽬现状中，在请求体⾥写{code: 200}⼏乎成了某些⼈眼⾥的业界规范了啊！HTTP码⽆脑200啊！这咋解释？！其实很好解释，这就是半瓶⼦咣当的程序员对于HTTP码理解错误，前端对后端说⼀句：“你要给我返回状态码啊”，后端就屁颠屁颠的把码放到请求体⾥了，前端看到后，⼼想：“⼜不是不能⽤，算了，反正绝⼤多数情况下都是200”。所以，到今天，搞得这成了业界标准⼀样。⽽且⼀些框架本⾝就使⽤HTTP码200、code 500来报错。从业界来说，结果成了：1. 脑⼦⽐较清醒的程序员，⽤HTTP码表达状态，⽤axios拦截器对各种HTTP码做了处理。2. 脑⼦不清醒的程序员，⽤code表达状态，axios拦截这个code，当然，最后肯定能跑通。但是，这显然是不规范的。常⽤状态码都有什么？建议不要超出这⼏个，这⼏个⾜够⽤。200请求成功201创建成功 专门⽤于创建新的记录的时候301永久重定向 ⽹址永久变更成另外⼀个⽹址302临时重定向 ⽹址临时变更成另外⼀个⽹址400⽆效的请求 请求的⽹址⽆效等401没有登录 需要登录才能访问403没有权限 虽然登陆了，但是没有权限404请求资源不存在 请求的东西不存在，⽐如某个⼈的信息500服务器端错误 服务器端发⽣了错误业界⼤公司，谁在⽤{code: 200}？⼀个不存在的公司，FaceBook，就在⽤{code: 200}。⾕歌等公司在⽤状态码200。再⽐如现在有个流⾏的java+vue后台系统，若依，官⽅演⽰的code我们看⼀下，它不是{code: 200}：P码不是200的话，能返回响应体么？当然能，包括HTTP 404错误，都能返回你想要的JSON格式的响应体。只在HTTP码写，前端能精准捕获吗？这个问题才是核⼼关键！你在HTTP码写的飞起，但前端捕获不了，不也是⽩扯么？我们测⼀下：原⽣Fetch成功时：服务器返回404时：跨域，但⽬标服务器⽆效时：ery这种⽅法是可以精确捕获各个错误代码的：$.ajax({ dataType: "json", url: '', statusCode: { 200: function(err) { (err); }, 404: function(err) { (err); } },});成功时：返回JSON本⾝。404出错时：os利⽤响应拦截器拦截⼀下：( function (response) {// 对响应数据做点什么 return response; }, function (err) { (se); });成功时：404出错时，se打印：结论市⾯上主流的ajax库和原⽣Fetch都⽀持捕获404，⽽且都是存放在。其他的HTTP码也都是⼀样的道理，就不多说了。所以，有什么理由不使⽤HTTP码呢？？HTTP码到底怎么定？1. 成功的状态码⼀定是200，就⾏了。2. 关于失败的状态码，我专门说⼀下，其实并没有什么⼀定之规，只要保证：如果使⽤常见的HTTP状态码，⼀定要符合通常理解的规范；如果使⽤了⾃定义的状态码，⽐如1000以上的状态码，那就团队⾃⼰定就好了，定了就要遵守，别经常变来变去。3.
msg只是在弹窗⾥显⽰，不要拿msg当做出错的判定依据，必须只拿HTTP码当做依据。最后⼀个问题，响应体应该怎么写？先说GET的响应体{ msg: null, rows: [...], total: 14 }1. 不要写code，不要写code，不要写code！2. msg在200前提下就null，因为成功前提下没有必要弹窗提⽰，除⾮极少数场合真的需要弹窗提⽰，不在200前提下可以写明到底什么出了错。msg的内容就是给中国⽤户看的可阅读的提⽰，会由前端组件放到提⽰框⾥，因此，绝对不要写“success”或者“err”这种⿁！！3. rows也可以叫list，强调的是数组解构，空数组则返回[]。不是数组的话，也可以叫result，result可以是基本类型也可以是⼀个对象。不要使⽤data作为字段，因为data意义不明确。尽管现在业界普遍使⽤data，但是加上axios封装响应体也会加上data，结果会写成这种取值，很容易脑⼦短路。4. 不要字段套字段，应尽量扁平。5. total是可选属性，表⽰数组资源总数。还可以加其他的字段传递别的数据。6. 在HTTP码不是2开头的情况下，除了msg，不要有其他属性。然后说POST、PUT、DELETE的响应体{ msg: '修改成功'}1. 如果200前提下，就返回msg就可以了，修改就是“修改成功”，删除就是“删除成功”，新增就是“新增成功”、“创建成功”等等的。2. 总会有失败的可能，⽐如删除失败，资源被别⼈先删了，你再删就是删除失败，这时候HTTP状态码不应是200（具体是多少看你们团队的规范），msg应当是删除失败：资源已被删除这类提⽰。其他的，⽐如“⽀付成功”和“⽀付失败”，⼀般来讲，成功，则页⾯路由会变化，进⼊下⼀个环节，失败，则原地弹出提⽰，可能要求⽤户换⼀种⽀付⽅式或者放弃⽀付，因此，失败的HTTP状态码不应是200（具体是多少也看你团队的规范），msg应当是⽀付失败：卡余额不⾜这类的话。
发布评论