系统服务化构建-状态码设计要点

Code状态码码是接口设计中的常见概念，本文主要讨论接口开发中Code码设计。从客户端和服务器端开发的角度，给出具体的工程实践建议和思考。

从笔者之前的一份接口文档定义开始说起，文档中定义的服务端接口输出格式如下

接口输出格式

返回数据由两部分构成，第一部分是对结果集的说明，第二部分是data节点

{
    "code": 4302,

    "message": "no sign",

    "time": 1487832032,

    "data": []
}

第一部分，无论错误与否，都会有如下片段。

code：信息代号

message：信息描述

time：接口返回时间

第二部分是具体数据如下：

data节点

我们可以 看到code=4302，4302并不是一个HTTP 协议状态码，而是一个业务状态码，是业务领域的含义，并非我们常见的HTTP 协议层面的响应状态码。

业务状态码与HTTP 状态码

在REST 接口设计规范中，我们通常都会被引导为这里的Code 应该是HTTP 协议状态码 200，404 或者501等。

实际上这是实践中的一种折中的方式，Code 会包含HTTP状态码和业务状态码

业界为什么会有这种实践，与客户端的解析数据方式有很大关系，下文中会给出答案。

说到这里，我们引出了两个概念，一个是业务状态码，一个是HTTP请求状态码。

两个概念很好理解

业务状态码

业务状态码是服务端给出的关于业务描述的码，用于客户端明确得知本次请求的资源的状态情况。上文例子中的4032被认为是一个缺少签名sign的业务状态码。有业务状态码输出表明当次HTTP 请求是通的。

业务状态码是可变的，没有业界标准，是一种资源状态描述，与HTTP响应状态码也不存在对应关系。

如下文图片HTTP-200 显示，接口是通的 HTTP 状态响应返回 200，但是业务没有执行成功，code用1 表示。