几种不同风格的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种

1. 数据没有冗余（没有什么 status和success），传输速度快。
2. 可以使用到HTTP标准状态码。这种API具有开放性。调用者通过你的HTTP状态码大致知道什么问题。

比如你访问401状态码，开发者就知道需要登录才能调用这个。
而其他的都是返回

{
    "status": 0,
    "message": "xxx"
}

需要一次解JSON才能得到具体操作，而且上例中貌似还要判断message里面包含"未登录"之类的字符

Answer 5

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

Answer 6

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