在繁杂的业务需求中，如何找到API设计的平衡点
这是学习笔记的第 2150 篇文章
关于API设计，有什么好的设计方法，或者说如何来构建一个相对健壮的后端API设计体系？我觉得还是在不断的实践中犯低级错误逐步积累起来的，或者是到了不得不改的时候才会造成这种变革和重构的过程。
比如说现在服务的后端有20个接口，基本人为还可以做好基本的配置管理。而一旦接入了业务流程，很多对象实体（模型）层产生了状态交互，那么这个复杂度就会高很多，而在逻辑实现或者API逻辑实现中，这块就很容易产生一个问题，那就是不断打补丁。
比如A的状态变更，会导致B状态变更，B的状态变更会导致C状态变更，在程序里面就需要不断的调整，添加逻辑。如果这样的关系越来越复杂，人为是很难统一管理起来的，基本上就处于崩溃的边缘，疲于应付，一种就是增加无穷无尽的API,满足业务需求，成为典型的密集型，另一种情况就是修正无穷无尽的业务逻辑问题，成为一团乱麻。
我们目前的情况没这么糟糕，但是从扩大的业务需求和维护管理来看，已经逐步显示出不少问题。
那么回过头来，我们来想一个本源的问题？
什么样的API设计是好的设计，公认的一种实现就是File API 的主要接口（以C为例，很多是 Posix API，选用比较简单的I/O接口为例
int open(const char *path, int oflag, .../*,mode_t mode */);
int close (int filedes);
int remove( const char *fname );
ssize_t write(int fildes, const void *buf, size_t nbyte);
ssize_t read(int fildes, void *buf, size_t nbyte);
为什么File API 是经典的好 API 设计？
File API 已经有几十年历史（从1988年算起，已30年），尽管期间硬件软件系统的发展经历了好几代，这套 API 核心保持了稳定。
API 提供了非常清晰的概念模型，每个人都能够很快理解这套API背后的基础概念：什么是文件，以及相关联的操作（open, close, read, write），清晰明了；
支持很多的不同文件系统实现，这些系统实现甚至于属于类型非常不同的设备，例如磁盘、块设备、管道（pipe）、共享内存、网络、终端 terminal 等等。这些设备有的是随机访问的，有的只支持顺序访问；有的是持久化的有的则不是。然而所有不同的设备不同的文件系统实现都可以采用了同样的接口，使得上层系统不必关注底层实现的不同，这是这套 API 强大的生命力的表现。
我来总结下在API设计中自己感悟的一些小技巧，比如我们对于业务开放接口，不希望有20个功能，开放20个不同的接口，可能对于业务来说，我开放一个接口或者少数几个接口就行，而对于参数等可以根据不同的逻辑场景有所差别，比如下面的API，有一个统一的访问入口，比如是v1/api/user_info
对于这个API下面我们可以定义一系列的相关接口，可以通过不同的code来定义区别。
另一个层面来看，我们设计的Model或者Object实体，其实从数据模型层设计来看，无非就是对于数据对象的增删改查操作，而这些增删改查操作也会随着实体的属性复杂度情况而提供相应的方法。
对于业务访问来说，其实是希望从业务视角来进行抽象，比如创建用户，修改用户资料，销户等操作，都是在业务层面来定义的，随着这些变化，会涉及相关的对象实体变化，而这样基于流程的变更也更贴近业务场景。
所以整个逻辑串联起来就会是下面这样的流程，而在这个过程中我们需要对已有的model层面进行细化的设计，对于model层面的增删改查属于内部的API,而对接业务层的则是FlowControl部分的API,他们有着不同的定位和权限隔离，比如对外业务我们不能提供Model层的增删改查接口，而需要统一交由流程层来进行对接。
小结：
在需求不清晰，管理混乱之中，需要找到工作的平衡，而需要更持久有效的管理，和这些管理设计是分不开的。
近期热文：