这个章节讨论一个当代应用开发需要具备的但是没有被原始的12 factors覆盖到的一个方面。不考虑你正在开发的应用类型，假设你正在开发一个云原生应用，然后你的终极目标是让这个应用成为一个微服务系统内的一部分
假设你已经全面拥抱了本书讨论的其他因素，你正在构建云原生应用，在你提交完代码到你的仓库之后，自动跑完了测试用例，同时也在几分钟以内发布了一个版本到某个环境
现在，您组织中的另一个团队开始构建与您的代码进行交互的服务，很快，您将有多个团队，所有团队都在水平依赖别人的服务上构建自己服务，这些服务都在不同的发布节奏上
如果没有一个准则来约束这个过程，系统集成将会成为一个噩梦。为了避免集成失败，也为了让你意识到API应该是你开发过程中的一等公民，API first给了团队更具抗干扰性的公有约束，而不用关心内部的开发细节
尽管可能你并不打算开发某个生态中的一个微服务，花费少量的精力去遵守API first这条准则在将来仍然有可能给你带来不错的回报
如今，“移动优先”的概念越来越受关注。它指的是从项目一开始就抱定一个想法：你的应用最终可能会给移动设备提供接口。同样，API优先意味着您要构建的是供客户端应用程序和服务使用的API
正如本书开头提及的，云原生不仅仅是一个规则列表，它是一种哲学，对于我们中的某些人来说，甚至是一种生活方式。这些准则不一定对应到一个特定的云平台提出的要求，但对于构建现代应用程序的人和组织至关重要，这些习惯将为将来云环境的变化做好准备
在做出的每个决定和编写的每一行代码的时候都需要考虑到这条准则，即通过使用API去满足应用程序的每个功能要求。甚至是用户界面，无论是网络界面还是移动界面，实际上都不过是API的使用者
通过首先设计你的API,你能够真正开始编码之前就与你的利益相关者（你的内部团队成员，你的客户，甚至是你的组织内其他有可能消费你的API的人）开始沟通了，这种合作方式允许你更淡定的去编写功能代码，mock你的接口，编写公开化的文档
如今，您会发现有无数工具和标准来支持API First开发。 API规范有一种标准格式，该格式使用类似于Markdown的语法，称为API Blueprint。这种格式比JSON（或WSDL，博物馆中的遗物）更具人类可读性，并且可以被代码用来生成文档甚至生成服务器mock程序，这在测试服务生态系统中具有不可估量的价值。诸如Apiary之类的工具套件提供了诸如GitHub集成和服务器模拟之类的功能。如果有人想调用你的API，您要做的就是给它一个指向您在Apiary上的应用程序的链接，在那里她可以阅读您的API Blueprint，查看调用API的示例代码，甚至可以模拟调用执行
换句话说，没有理由去拒绝API first,这种模式可以应用于非云软件开发，但是它特别适合云开发，因为它具有云原生应用程序开发的很多特点，比如说快速原型制作，支持构建微服务生态以及促进自动化部署测试和持续交付的能力
这种模式是“合约优先”开发模式的扩展，这种模式下，开发者专注于应用边界，开发团队各自维护自己的服务，只要通过集成测试服务器保证接口集成点测试通过，那么就可以假设服务之间调用是工作良好的
API first将组织从瀑布模式和过度提前设计的模式中解放出来，允许产品各自演进成独立的系统，可以满足未来不可预测的需求
如果您建立了一个大的单体应用，甚至一个大的紧密耦的生态，那么您响应新需求或创建现有功能的新使用者的能力就会受到阻碍。从另外一个角度来讲，如果你接受了这种观念，即所有的应用都是一种后端服务，并且他们被设计成API first ,然后你的系统将能够自由生长去适应新的需求，去为已经存在的服务容纳新的消费者
生活，饮食和呼吸API-first生活方式，您的投资将成倍增长