除了rest api外还适用于其他API

1. 错误消息

错误消息应该帮助用户轻松，快速地理解和解决API错误。一般来说，在编写错误消息时，请考虑以下准则：

不要假定用户是API专家。用户可以是客户端开发人员，操作人员，IT人员或应用程序的最终用户。
不要假定用户了解服务实现或熟悉错误的上下文（如日志分析）。
如果可能，应构造错误消息，以便技术用户（但不一定是您的API开发人员）可以响应错误并进行更正。
保持错误消息简练。如果需要请提供链接，这样困惑的读者可以提出问题，提供反馈或获取更多信息（这些信息不一定适合在错误消息中展示）。如果不合适，就可以使用详细信息字段展开。

参照“Google API Design Guide”，我们为错误定义一下字段

2. 错误码

错误码能为我们带来什么？

为了达到上述的目的，我们需要对错误码的命名及使用做一定的约束。

错误码为7到8位数字：ABBCCCC

A：错误来源
- 1：表示错误来源于用户，比如参数错误，用户安装版本过低，用户支付超时等问题；
- 2：表示错误来源于当前系统，往往是业务逻辑出错，或程序健壮性差等问题；
- 3：表示错误来源于第三方服务，比如CDN服务出错，消息投递超时等问题；
B：项目或模块的名称
C：自增且唯一表示具体某一种错误

不管是查询还是写入或更新操作，所有的操作成功都统一返回 0，代表操作成功。

编号不与公司业务架构，更不与组织架构挂钩，以先到先得的原则在统一平台上进行，审批生效，编号即被永久固定。

在获取第三方服务错误码时，向上抛出允许本系统转义，由3转为2，并且在错误信息上带上原有的第三方错误码。

前后端对于错误码的处理，分歧一直存在。有些团队中前端直接显示后端返回的错误码描述，有些团队中则在中台做了错误码到描述的转换，也有团队是在前端维护了错误码到描述的映射关系。

以后端返回描述为准的场景下，每当交互、产品需要更改对客户的展示，会导致后端系统频繁变更发布；同时，当同一个错误码需要在不同的前端页面展示成不同的描述时，后端将无能为力。
以中台来转换后端错误码对应的描述，则会让开发中台的同学非常痛苦，因为中台后面可以对应众多的后端系统，任意一个后端系统的变更都有可能需要中台开发人员配合着一起改代码。
以前台来维护错误码和描述的关系，是这三种方式中比较多用的，但依然和前两种方式有共同的痛点，那就是交互、产品有错误提示的变更诉求时，或是后端系统增加了新的错误码时，前端开发人员都需要做对应的改动并重新发布。
维护一个错误码字典表，将由错误码后台将映射关系统一存储至数据库，并通过错误码的API将其暴露给前端页面展示

个人倾向于前端展示的错误描述要做一次转义。因为通常我们的message都是写给工程师看的，但是在不同的场景下，同样的错误，可能需要给用户看到不一样的错误提示。

比方说 20000-29999表示订单创建失败：

这两种错误情况如果是给用户看，可能就只适合看到：很抱歉，您有一个正在进行中的订单，请到我的订单列表中处理。

但是对于API来说，返回的信息又必须是准确的，但用户看到的就必须转译。

Java开发手册（嵩山版）

https://juejin.im/entry/6844903482089193486