几种不同风格的json返回值应该怎么取舍

Question

后端回给前端的数据格式有很多种。

下面以一个登陆返回的数据为例子，这里写了一下它们的成功和失败的请求报文。

第一种。最简单粗暴的。通过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"
}

上面的几种格式应该怎么选择呢。或者有其他更好的格式。如果上面有给你不明所以的格式。那大概就是我写错了。直接跳过就好了。讲讲看的明白的格式就好了。谢谢

Answer 1

从项目上讲，感觉不搭噶，像http返回的状态码，像验证问题，网络问题，这些其实和传输协议直接挂钩，像自己写的业务逻辑返回值，例如密码错误，或者登录成功，这个在请求上是已经成功的，个人觉得，这两种方式不能混为一谈，因为是不同的层次，，当然前台有必要的还是要处理 请求失败时 回调。例如用error函数，如果是 业务返回成功的话，前台错误捕获是不行的

Answer 2

个人感觉第三种好

Answer 3

一般开发用的比较多的是第四种

Answer 4

推荐第1种 数据没有冗余（没有什么 status和success），传输速度快。 可以使用到HTTP标准状态码。这种API具有开放性。调用者通过你的HTTP状态码大致知道什么问题。 比如你访问401状态码，开发者就知道需要登录才能调用这个。而其他的都是返回 { "status": 0, "message": "xxx" } 需要一次解JSON才能得到具体操作，而且上例中貌似还要判断message里面包含"未登录"之类的字符

Answer 5

第一种是最规范的方式，国内实际使用中好像第四种比较常见。推荐第一种，很多APIDoc生成工具（比如Swagger、APIDoc）只支持第一种方式，而且大多数开源项目API也使用的是第一种方式。

Answer 6

第一种即可，通过判断返回的http状态码判断请求是否成功。