规范
错误码和返回机制
与此同时啊，建议不要试图创建自己的错误码和返回错误机制。
很多时候呢，我们觉得提供更多的自定义的错误码有助于传递信息，但其实，如果只是传递信息的话，错误信息字段可以达到同样的效果。
此外，对于客户端来说，很难关注到那么多错误的细节，这样的设计只会让API的处理变得更加复杂，难于理解。
因此，我的建议是遵守Restful API的规范，使用HTTP规范的错误码。例如，我们用200表示请求成功，用400表示错误的请求，而500则表示服务器内部的错误。
当Restful API接口出现非200的HTTP错误码响应时，可以采用全局的异常结构响应信息。
返回体结构
这里列出了最为常用的几个字段，讲一下它们各自表示的含义。
-
其中code字段用来表示某类错误的错误码，例如前面介绍的无效请求、缺少参数、未授权资源、未找到资源、已存在的错误。
-
而message字段用来表示错误的摘要信息，它的作用是让开发人员能快速识别错误。
-
server_time字段，用来记录发送错误时的服务器时间，他可以明确的告诉开发人员发生错误时的具体时间，便于在日志系统中根据时间范围来快速定位错误信息。
此外，不常用字段会根据不同的情况做出有不同的响应。
如果是单条数据，则返回一个对象的json字符串；如果是列表数据，则返回一个封装的结构体，其中涵盖count字段和item字段。
count字段表示返回数据的总数据量。需要注意的是，如果接口没有分页的需求，尽量不要返回这个count字段，因为查询总数据量是耗性能的操作。
此外，item字段表示返回数据列表，他是一个json字符串的数组。
简单性
简单性的主要宗旨是遵守最少的知识原则。
怎么来理解呢？其实就是客户端不需要知道那么多服务的API接口，以及这些API接口的调用细节，比如设计模式的外观模式和中介者模式都是它的应用案例。
如图所示，外观接口将多个服务进行业务封装与整合，并提供了一个简单的API调用给客户端使用，这样设计的好处是什么呢？就在于客户端只需要调用这个外观接口就行了，省去了一些繁杂的步骤。
