最近呢，在做 api 的设计
对于设计，一方面是对于后端 server 框架的设计，另一方面呢，是对于整个 api 体系的设计
在这里呢，我们来理理思路，先来大致分一下块
风格就不用说了，我们就用 restful 风格，接下来：
- IDL，也就是我们所说的接口描述语言
- server 框架，整个 api 服务的核心驱动
- 版本控制
- 还有一些辅助工具，比如说，自动化工具、认证授权、监控上报、日志记录、检索等等
然后呢，我们就来分别说说设计开发中的一些感触
IDL
顾名思义，IDL 是我们整个 api 体系的核心模型，基本上所有的东西都是要基于我们的 IDL 的，在使用的选择上有很多，比如 Yaml、Json、xml、PB 等等，这些都可以作为接口描述语言，同时呢，各有优劣，在这里呢，我们考虑了以下这几种：
Json：
Json是一种稳定并得到广泛应用的序列化格式，浏览器包含对该格式的原生解析能力，浏览器内建调试器也能很好地显示这种内容。唯一不足在于要具备 Json 解析器/序列器，好在基本所有语言都已提供。使用 Json 最主要的麻烦在于每条信息会重复包含属性名，导致传输效率低下，同时呢，Json 对于一些 api 开发过程中可能出现的特殊需求可能会处理不好，比如说，字段之间的依赖关系，就不容易描述出来
Yaml：使用
Yaml来定义我们的 api 模型的话，可谓是非常的简洁明了，但是对于 api 模型中的一些复杂结构，以及一些字段的自检测，并不能够很好的支持，同时，这个格式也不容易在开发中进行约定，可能会引起一些不必要的麻烦
PB：PB 全称是
Protocol Buffers，是谷歌创建的一种基于二进制连接格式的接口描述语言。在解析和网络传输方面Protocol Buffers更高效，并经历了谷歌高负荷环境的考验，不足在于一些语言的支持并不是很好，主要还是对于 C、python 和 java 的支持，并且呢，在.proto文件的共享和编译方面会产生些许额外开发负担
xml：这个大家就都非常熟悉了，相对于
Json和Yaml，xml就显得有些笨重了，但是 xml 能够很好的应用于各种特殊的场景，能够根据不断的线上需求进一步的扩展，并且可以直接通过xsd进行自校验，从功能上来讲，或许会更加完善一些
因为 IDL 是我们 api 的核心，以后的各项业务基本都要围绕 IDL 展开，所以需要能够功能完善，便于扩展，并且在开发中能够有一些自动化的工具来进行约束，so，最终呢，还是决定采用 xml 的形式
server 框架
核心代码非常的简单，只需要写一个 route 来实现路由调用就行了，但是，为了辅助他能够正常的调用，我们就不得不实现更多的一些辅助功能了
可以来看一下我的基本的目录结构
Framework
│
├── Auth 认证、鉴权模块
│
├── Base 基础服务
│
├── Client 各种端服务
│
├── Common 公共组件
│
├── Core 核心调度逻辑
│
├── Coroutine 协程调度实现
│
├── Exception 异常处理
│
├── Http 协议实现
│
├── Log 日志上报，监控模块
│
├── Pool 连接池（资源池）
│
└── Resource 资源模型
同时呢，开发过程中要降低各模块间依赖关系，就比如说，与其 new 一个对象，不如采用 set 的方式来解耦，预期继承，不如采用组合的方式，保证各个模块的独立性，同时呢各模块间又要有一个通讯通道
为了实现一些特殊的需求，我们采用协程调度来实现非阻塞 IO，当然，这里我们就需要实现一个单独的服务端口监听，就好比 swoole 或是 workerman 那样，编写独立的服务进程
ok，上面也提到了，核心代码只需要实现一个 route 路由就行了，但是在路由前后，要记得留出认证、鉴权接口，同时呢，对于运行时的异常也要及时捕获上报，同时记入日志，方便调试
对了，除了这些 server 服务依赖，数据也要注意哦，最好是能够在原始数据之上再单独抽离出来一层数据接口层，不要直接操作原始数据
这些核心服务完成后，剩下的就是客户端和服务端代码，这个就可以根据实际的服务去自由发挥了，对于 api，我们也可以把客户端代码称之为 SDK，同时呢，为了方便以后的开发维护，可以统一编写自动化工具生成，对于不同语言对应的做支持
OK 了，上篇就先写到这里吧，主要说了对于 server 框架以及 IDL 的设计选择思路
下篇呢，会主要对于 api 的版本控制，发布，以及一些自动化工具进行一些分享
From: 一名热爱动漫的攻城狮
