后端回给前端的数据格式有很多种。
下面以一个登陆返回的数据为例子,这里写了一下它们的成功和失败的请求报文。
第一种。最简单粗暴的。通过HTTP状态码来表示失败和成功的状态。只有在错误或者其他的情况的时候才会有message
信息。
# 登陆成功
HTTP/1.1 200 OK
{
"user" : { "name" : "..." , "age" : "..." }
}
# 密码错误
HTTP/1.1 400 Bad Request
{
"message" : "password invalid"
}
第二种是前面一种的类似的版本。不过它会在任何时候都带上message
信息。
# 登陆成功
HTTP/1.1 200 OK
{
"message" : "success" ,
"user" : { "name" : "..." , "age" : "..." }
}
# 密码错误
HTTP/1.1 400 Bad Request
{
"message" : "password invalid"
}
第三种的状态码永远都是200。因为它有属于自己的状态码,非HTTP协议规定的状态码。一般是自己的业务的状态码。
# 登陆成功
HTTP/1.1 200 OK
{
"status" : 0,
"message" : "success" ,
"user" : { "name" : "..." , "age" : "..." }
}
# 密码错误
HTTP/1.1 200 OK
{
"status" : 419
"message" : "password invalid"
}
第四种。和第三种混用。包含了自己业务的状态码还有HTTP规定的状态码。
# 登陆成功
HTTP/1.1 200 OK
{
"status" : 0,
"message" : "success" ,
"user" : { "name" : "..." , "age" : "..." }
}
# 密码错误
HTTP/1.1 400 Bad Request
{
"status" : 419
"message" : "password invalid"
}
上面的几种格式应该怎么选择呢。或者有其他更好的格式。如果上面有给你不明所以的格式。那大概就是我写错了。直接跳过就好了。讲讲看的明白的格式就好了。谢谢
从项目上讲,感觉不搭噶,像http返回的状态码,像验证问题,网络问题,这些其实和传输协议直接挂钩,像自己写的业务逻辑返回值,例如密码错误,或者登录成功,这个在请求上是已经成功的,个人觉得,这两种方式不能混为一谈,因为是不同的层次,,当然前台有必要的还是要处理 请求失败时 回调。例如用error函数,
如果是 业务返回成功的话,前台错误捕获是不行的