谈谈接口错误码

对于程序员来说，接口是再熟悉不过的了，前端使用后端提供的接口进行交互。为了让前端知道调用的是否产生异常。我们需要定义错误码，规定那些错误码是正确的调用，那些是错误的调用，前端根据错误码进行相应的逻辑处理。那如何制定规范的错误码呢？让我们来谈谈吧。

之前我有见识过直接使用HTTP CODE值当中错误码的。直接使用200当作正确的调用，错误的调用就用其他值，当然他们避开了常见的错误码，如：404、403、500等。

但是这样有两个问题：

1. 错误码的范围有点少了
   对于一个中等型的后端，错误码都是比较多的，一般以百为单位
2. 错误码容易让人误解，比如调用接口返回错误码为404，前端当他是业务异常呢还是接口不存在了呢？http code使用来描述http状态的，直接使用http code当作业务异常，这样容易产生冲突，肯定是不妥的。http code含义

接口错误的类型

接口错误分为两大类系统错误和业务错误码

• 系统错误码： 一些通用错误信息的定义，一般用于指示开发者正确的进行接口调用和告知调用者接口服务的状态信息。
• 业务错误码：根据具体业务流程提示或诱导用户进行正确的操作，如用户登录时，账号密码输入错误，接口错误码和提示信息会引导用户重新检查账号密码的正确性并进行重试。

接口错误码作用

接口错误码的制定在系统开发过程中是非常重要的，规范的错误码使的接口更加易用,同时在后期的维护中，错误码可以让我们快速定位到bug。
一个好的错误码规范应该要有一下几点

1. 诱导接口调用者使用正确的调用方式
2. 指示调用方依据不同的错误码做逻辑控制处理
3. 指示用户，引导用户进行正确的操作
4. 明确指示服务器接口处理异常信息，便于开发人员及时发现与排查

为了达到上述目的，我们会将接口返回的数据按下面的格式：

{
    "code":200,
    "msg":"",
    "data":null
}

code用来指示错误码，msg用来指明接口调用的附加文字信息，data用于保存接口实际要返回的数据。
或者使用下面的格式：

{
    "code":1,
    "strCode":"Login:AccountNotFound",
    "msg":"未找到该账户信息，请核实后再登录！",
    "data":{}
}

这个就是比上面多了一个strCode字段，它属于字符型的错误码，用来直接的通过文字进行描述错误的位置。使用场景是当我们一个错误码用在了多个地方的时候，这样我们就无法通过错误码进行bug定位。这个时候strCode就应该发挥作用了。

接口错误码需要具有哪些能力？

1. 易于维护，错误码要便于维护
2. 易用性，错误码的定义要对开发人员友好，最好开发人员不需要关心错误码的值
3. 灵活可控，错误码可以手动指定，也可以自动进行维护，而且支持错误码自动分段和手动分段

接口错误码规范

谈了这里多让我们开始具体谈谈接口错误码的制定吧

对于接口使用方来说，调用接口我们需要知道如下：

1. 接口是否调用成功
2. 接口调用失败的原因
3. 接口调用失败，应该做那些逻辑操作

第一二两点我们都可以通过code进行判断，第三点就是我们要重点讨论的了。
失败的逻辑操作用那些呢？比如最常见的就是登录凭证失效或错误，如果我们将登录凭证失效或错误的数据按下面的方式返回：

{
    "code":300,
    "msg":"",
    "data":null
}

这个错误是在所有的接口中都会出现的，如果是上面的格式，那前端要判断多次才能确定这个错误然后执行相应的逻辑。首先是判断http code是不是200，然后判断code是不是0，最后判断code是不是300。
但是如果我们直接将它定义为http code为506。这个时候判断次数就减少了，其实不仅是判断次数。更重要的是错误升级了。那什么是错误升级了?
对于接口调用，一般情况：http成功次数>业务成功次数>业务失败次数>http失败次数。所以对于经常发生或是很多接口都会出现的错误，我们可以将其转换成http错误，这样判断次数减少，同时方便调用方在http错误的情况编写统一的错误处理。

总结一下:调用方其实并不在意接口出现错误到底是后端的哪一个模块、哪层、那个环节、那个控制器。它只想知道这个错误我该怎么做。是直接将msg显示给用户看，引导用户正确的操作。还是将该错误msg包装显示通用的错误类似服务器睡着了，请稍后再试。还是将错误直接忽略。

所以code只是为了后端知道哪里有问题。接口要满足调用方的要求，我们可以在http code中找几个code值，让前端知道，这个错误是否要展示还是忽略。