对于现在的绝大多数人来说，网站和移动应用已经跟空气和食物一样成为生活的必需品。然而在网站和移动系统不断演化的过程中，前后端分离是系统架构演化的一个重要分水岭。

　　随着系统逻辑和展示层分离的过程中，API 是一个实现这种分布式应用架构的重要机制，从早期单纯的 WebService 到 RESTful，API 的设计方法、技术和理念发生了巨大的变化。然而 API 的设计实在是陷阱重重，一不小心就会落入其中，从而连累整个系统。

　　如果单纯地考虑功能的话，大部分服务端开发工程师都可以设计和实现出一个说得过去的 API，但一旦有多个互相关联的 API，或者当系统压力达到一定级别时，就会有不少问题出现，甚至导致系统崩溃。

　　我们可以来看看常见的误区在什么地方。

　　1、 API 就是 RESTful API

　　观点：RESTful 是现在很流行的一种 API 设计风格，有大量的文章在推荐这种方法，atv，因此我们就需要按照这种风格的要求来设计API，并且要实现全套的设计！

　　真相：完全不需要！

　　事实上 RESTful 只是一种设计思想，并不存在具体必须遵守的规则。在不同的应用系统中，API 承担了不同的各种职责和功能，针对不同的应用场景可以使用相应的规则，适用就好。尽管有一些类似于Richardson成熟度模型这样的理论，但也都不是必须做到的。虽然最高级别的成熟度是很有用的，但也要求整个系统以特定的方式运作，对于绝大部分的系统来说，低一些级别的成熟度一样工作良好，并且同时不需要花费太大的代价。

　　如果实现了比较完整的 RESTful API，那么会有一些好用的工具和代码可以利用，但如果自己实现，也未必会有很大的代价。

　　2、 API，不过就是一段 Java 代码么

　　观点：API？不过就是一些 Java 代码暴露一个 HTTP 地址么，找个会做 Java 的人上就行。

　　真相：大部分情况下都不是这样的。

　　这种说法，和“只要人会说话，就能进行感人的演讲”一样可笑。

　　（图样图森破）

　　软件工具的使用只是一种简单的技能，但在工具背后的思想是需要经过经验的积累以及各种周边知识的共同理解才能做到。

　　API 的设计与其说是一种技能，不如说是一种艺术，交流的艺术。除了代码编写以外，更多的是架构上的设计。API 是整个服务端系统暴露到客户端的接口，是所有业务逻辑提供给外部的界面，如果对于系统的整体要求和架构不了解，很难设计一个合用的 API 系统。

　　3、 和交互绑定的 API 设计

　　观点：API 是给客户端用的，在现在 App 大行其道的时候，移动端的同事说，我们需要简化网络交互，所以每个页面只需要一个 API ——什么？我要调用8个 API？不行，太慢了，只要一个，把所有的数据都放在一起给我吧，谢谢！

　　真相：这样的做法会导致 API 最终完全不可用。

　　没错，从性能的角度上看，确实这样是比较好的，但是，有没有想过，如果移动端页面设计改变了怎么办？一旦增加或者减少这个页面所需要的数据，那么这个API 立刻就变得没用了，重新设计一个？算了吧，API 升级的代价太高了，于是越来越多的重复 API 就出现了。

　　前后端分离的理念在于把业务逻辑和展示分离，API 作为业务逻辑的体现，以业务逻辑作为设计原则，比靠拢易变的展示层要准确和靠谱得多。从这个角度上说，引入一个中间层来适应展示的变化会更加适合。

　　4、 我的 API 是我的，你的 API 是你的，不互通的 API 设计

　　观点：系统 A 提供了一组 API，系统 B，恩，另外一个系统，所以我们需要另外一组 API，但是，不好意思，我不知道 A 是怎么做的，并且我也不关心。

　　真相：这是一种系统分裂的征兆，是系统业务逻辑混乱的表现。

　　如果把应用程序接口比做用户接口的话，这样的说法就很奇怪了。作为一个公司下的不同系统，长得完全不一样，互相之间没有任何关联性，这样用户在使用的时候会很别扭。如果把系统当成一个人，这样的设计就和这个人有两张脸一样奇怪。作为系统的架构师，要为全公司设定一个一致的API规范，程序员们对接入各个系统可以有明确的预期，并且非常有助于在系统和客户端之间共享代码，简化开发和维护的成本。

　　5、 API = 数据库