背景
在做接口设计时，对于一些异常的响应如何处理一直是开发者们头疼的问题，不同的团队有不同的规定。有的团队会利用http状态码去表示各种情况的异常。有的团队会针对异常统一的返回200，然后在数据中增加一个code参数，用于表示各种异常的错误码，message参数中表示具体的错误信息。如下图所示：
那么到底两种方案有什么区别呢？我试着问了问ChatGPT。
ChatGPT这么说
问：在做接口设计时，可以用 http 状态码表示一些异常情况。也可以统一设置 http 状态码为 200，然后在返回的数据中添加自定义的 code 码。这两种方式各有什么优势和劣势呢？另外请提供一个选择上的建议
答：
在做接口设计时，可以用 http 状态码表示一些异常情况。也可以统一设置 http 状态码为 200，然后在返回的数据中添加自定义的 code 码。这两种方式各有优劣，具体如下：
- 使用 http 状态码的优点是符合 HTTP 协议的规范，可以让客户端和服务器之间更容易地交换信息和处理错误。HTTP 状态码已经定义了很多常见的情况，比如 200 表示成功，404 表示找不到资源，500 表示服务器内部错误等。使用 http 状态码的缺点是有些情况可能不太适合用标准的状态码来表示，比如业务逻辑上的错误或者特殊的需求。虽然可以创建自定义的状态码，但是这可能会导致与其他系统或框架不兼容或者引起混淆。
- 使用自定义的 code 码的优点是可以更灵活地表示各种业务逻辑上的错误或者特殊的需求，比如用户未登录、余额不足、验证码错误等。使用自定义的 code 码的缺点是不符合 HTTP 协议的规范，可能会让客户端和服务器之间更难以交换信息和处理错误。比如，如果客户端收到一个 200 的状态码，但是实际上接口返回了一个业务逻辑上的错误，那么客户端就需要解析返回数据中的 code 码来判断是否成功，并且根据不同的 code 码做出相应的处理。
综上所述，在选择使用 http 状态码还是自定义 code 码时，需要考虑以下几个因素：
- 是否需要遵守 HTTP 协议的规范
- 是否需要与其他系统或框架兼容
- 是否需要表达非标准或复杂的业务逻辑
- 是否需要简化客户端和服务器之间的通信和错误处理
一般来说，建议使用 http 状态码作为主要的响应方式，并且尽量使用标准定义好的状态码。如果有特殊需求或者无法用标准状态码表示，则可以考虑使用自定义 code 码作为补充，并且在文档中清楚地说明每个 code 的含义和对应操作。
不得不说，ChatGPT果然强大，完全的解答了笔者的疑惑。总而言之，就是说咱们在设计接口响应时，如果是正常响应，那么就返回200和原本的数据就好了。如果是有异常的情况，则可以status code 和自定义code配合使用。一个最佳的实践建议是结合两种方式，即使用 HTTP 状态码表示基本的错误类型和语义，同时在返回数据中添加自定义 code 码表示具体的业务错误。例如：
1 | { |
这样既可以遵守 HTTP 规范，又可以提供更多的错误信息。
既然要遵守HTTP规范，那么我们就得知道HTTP规范如何规定我们怎么定义状态码的，于是我又问了ChatGPT。
问：HTTP状态码设置的规范是什么？
答：
HTTP状态码是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。 响应分为五类：信息响应 (100–199)，成功响应 (200–299)，重定向 (300–399)，客户端错误 (400–499)和服务器错误 (500–599) 。设置HTTP应答头往往和设置状态行中的状态代码结合起来。
问：有哪些默认的标准的HTTP状态码呢？
答：
默认的标准的HTTP状态码有很多，常见的有以下几种：
- 200 - 请求成功
- 301 - 永久重定向
- 302 - 临时重定向
- 304 - 资源未修改
- 400 - 错误请求
- 401 - 未经授权
- 403 - 禁止访问
- 404 - 请求错误
- 500 - 内部服务器错误
总结
不得不说，ChatGPT在搜索场景里，大大提升了我们的效率。虽然这些问题直接使用搜索引擎也能找到答案，但是我们需要自己花时间去各种浏览筛选汇总信息，而且搜索结果中，还充斥着大量的低质和无用信息。而现在，ChatGPT能直接把结果提炼出来，而且非常的精确，像一个非常有资历的大佬一般。当然，这也非常考验我们的提问能力，也就是说你得清楚的知道自己不知道什么（哈哈哈，有点绕）。