观点：API 设计？简单，数据库的操作映射一下好了。创建一个对象，修改一个对象，删除一个对象，赞！API 设计的生活是如此简单。

　　真相：等一下，作为API的使用者，客户端应用为什么需要知道数据库？难道不应该是业务驱动的吗？

　　很多 API 确实就是这样设计的，但如果只是单纯地按照数据库的结构进行设计，那么只能说是一个数据库的访问层而已，是SQL 语句的 HTTP 化…… 但 API应当反映的是业务内在逻辑，包括业务对象、流程和业务数据，在基于数据库的基础上，通过服务器端的业务层处理后才是 API 应当的结果。

　　6、 我的自留地 API，API 不开放标准

　　观点：我没打算开放 API 给别人用，所以也不需要遵守什么标准。

　　真相：标准意味着通用，有更多的简化。

　　话是不错，但标准的好处在于设定交流双方的一个基础，atv，作为服务器对外的交流接口，API 始终是设计得给人用的，不仅仅是公司内部，也有可能是外部；不仅仅是现在，也有可能是未来的人在使用。和代码规范一样，符合良好规范的 API 能够极大地改善可读性、维护性，即使不开放给外部，内部交流也会获益良多。

　　7、 我不说，你就不知道，API 的安全性

　　观点：这个 API 又没有公开，所以不需要加密的。

　　真相：在这个互联网上是没有秘密的，所以你不让人知道，不代表别人不会知道。

　　关于安全，这个是 API 设计中非常重要的一个需求，但很多 API 的设计师并不重视这个。最常见的借口就是这个，我不告诉别人，谁也不知道。但事实上，API 作为交流的工具，即使服务端不容易被窥视，但大量的客户端几乎是不设防的。破解一个客户端系统并不是一个多么困难的事情，因此了解这个 API 的调用也不是太复杂的事情。

　　此外，在网络上的传输也是不安全的，中间人截获信息的案例导致无数的系统被攻破。按照业界的推荐方法来设计 API 的安全传输功能，尽管开发的代价会略大一些，但远比自己自以为完美的设计安全得多。

　　写在最后

　　随着越来越多的人在使用互联网，用户界面（UX）设计的影响也越来越大，所有人都开始注重用户界面设计的好坏，然而 API 是业务逻辑的用户界面，是针对程序员的界面，避免这些误区陷阱可以让这些界面更加友好，在业务逻辑和展示层都能运作得更好。

　　本文作者：徐翎 Andrew（点融黑帮），任职点融网客户端开发总监，组建了移动和网站的开发团队，开发了点融网各款客户端软件。曾就职于微软等公司，参与过包括Hotmail 和Windows 在内的大型跨国际软件开发项目的研发。