1.3.4 应用程序接口

为了便于服务器和客户端之间、层与层之间以及模块与模块之间互相协作，需要定义一套清晰明确的接口来让它们互相调用。而这套接口，称作应用程序接口（Application Programming Interface，简称API）。

图1-1 全栈API接口示意图

正如前面所说，一个好的系统是前端与后端的结合，如何结合？如图1-1所示，前后端的系统实现都会分成若干层[6]。从图中可以看到前端的最底层API数据访问层就是通过API的远程调用通过互联网和后端的最顶层API表现层交换数据。好的API设计是前后端顺畅结合的关键，所以对于全栈工程师，日常工作中最重要的一环，莫过于设计和实现前端与后端之间读写数据的API。

Q&A 什么样的API才是好的API？

如果把计算机系统的模块想象为一支军队，那么API就是这支军队的操典手册。就和一支有战斗力的军队一样，要严谨而又不失灵活。好的API要拒绝有问题的“坏”请求，以免错误在不同系统/模块之间扩散。同时又能灵活地处理未来各种可能的新情况，而不需要经常改动接口。

因为API是跨系统/跨模块的互相调用，由于负责开发不同部分的程序员对系统的理解不一致，容易出问题，而出了问题又不好调试。所以API设计必须简单明确，让人一看就懂，就算没有文档，也能让人拿起来就用。

同样因为API是跨系统/跨模块的，每次升级都会牵扯很多地方，这造成升级很不容易，所以一套好的API必须经久耐用，且能兼顾将来的需求改变，并留有扩展的余地。

API会牵扯很多系统或者模块，正所谓牵一发而动全身，造成整个系统不易修改。而现今无论是早已如火如荼的移动互联网开发，还是方兴未艾的人工智能开发，都讲究需求快速变更，研发快速迭代。传统的API设计模式就显得有些捉襟见肘了。那怎么办？这样GraphQL也就应运而生了。本书中的GraphQL就是定义了一套灵活的API数据查询方法，极大地影响了现有的全栈开发方式。

说起API，很多有经验的读者可能已经想到了如雷贯耳的RESTful API，那它与GraphQL是什么样的关系呢？这还得从RESTful API的起源和它带来的问题谈起。