原文自国外Web开发公司crowd favorite，作者为 Steve Mathias， 传送门
之前我们公司开始试进行接口评审会，但是其实无论是哪个端，都对接口评审这项流程感到很迷惑，评审会具体是要得出很么结论？前后双发需要怎么在会议中配合和讨论？
于是我就在网上搜了下一些关于接口评估的文章，其中这一篇是说到如何确定接口的内容，以及怎么和其他团队配合去审核接口的。
什么是API？
应用程序编程接口，或者说 API，是一组允许对系统进行编程式访问的命令、程序块、功能或者统一的数据获取节点。
一个基于网站的 API 主要是使用简单对象访问协议（SOAP）或者表述性状态传递（REST）接口来构建。虽然 SOAP 在旧的应用程序中很常见，但是新的程序设计更偏向于使用 REST API 通过返回 XML 或者 JSON 来支撑更简单的编程访问结构。这些 API 允许那些经过身份验证的读写访问，并且大多数也支持对站点的某些不需经过验证的读访问。这对于使用 AngularJS、其他的 JavaScript 库或者原生的移动、桌面应用开发都非常有用处。
评估一个API
在任何涉及到 API 的过程中，就像其他的软件工作一样，设计阶段对于项目是否能获得长期的成功是占有一席之地。在这期间，我们检查了站点的给定的数据与现有的 API 端点和数据源进行比较，所有必须的数据、程序访问和组件都是可以用来满足应用程序的需求。在我们和 Starz Entertainment 团队的合作中，我们开启了一个通过设计流程来评估数据以及结构，并且在传达了我们的需求和期望，以交付一个建立在他们内部的使用 AngularJS 开发的内容管理系统（CMS）中高性能网站。
审查应用程序设计
为了确定我们需要在他们的 API 中获得什么信息，我们首先需要审查站点的设计，并且确定在客户端提供的静态设计中表现出来的，包括数据和行为的不同特性。我们必须重点关注那些可能以不同形式表示出来的相似信息，以及查找那种根据用户行为筛选、限制或者排序的类似列表或项。在开始的过程，我们还审查了那种看起来相同但显示不同数据的组件以便更好地提出一种可以将数据显示和数据本身分离开的体系结构。这要求能够将来自不同的响应数据转换成单一的、统一的格式，这种格式能够在不需要依赖 API 本身，通过统一的形式返回所有对象来展示代码。
在此阶段，还需要记录访问点之外的产品特点所需的任何数据。
审查可用的API方法
使用Starz Entertainment 团队提供的文档，并通过我们自己去研究端点，我们最终创建了一个文档映射 API 端点来标识站点的功能。在这期间，我们确立了 API 中提供的方法以及提供功能所需数据的端点。
如果任何端点都无法完全清晰地支持所期望的数据和交互，那么我们将详细记录遗留的需求并将其报告给客户端。我们越早实现这一步，就越有可能在给定的十年内准确地确定范围、评估以及完成项目了。
在可能的情况下，开发过程中应该记录那些在 API 中没有使用的端点，这对开发者有好处。有时这可以发现那些被遗漏的功能点，或者在其他情况，可以让 API 开发者去缩减和优化代码，提高代码的可用性以及应用的性能。