要实现API，需要做很多工作。 过度的计划可能会浪费能源，而缺乏计划则会导致灾难性的后果。 在本书中，您将获得一些解决方案，可让您分配必要的资源并在最佳时间内达到所需的效率水平。 如何在保持可靠性和易于配置的同时兼顾灵活性和性能？ API学院的四位专家向软件开发人员，产品和项目经理解释了如何通过将接口作为连续寿命的产品进行管理来最大化其API的价值。
本书的内容是基于我们多年的集体知识（Mehdi Mejuy，Eric Wilde，Ronnie Mitra，Mike Amundsen），包括我们自己和他人的API的创建，开发和改进。 它阐明了我们所有的经验。 我们确定了有效开发API的两个关键因素：对面向产品的方法的需求和正确的团队的形成。 我们还确定了管理此工作的三个重要因素：领导力，产品开发和API系统开发。
这五个要素构成了构建成功的API管理程序的基础。 我们向读者介绍所有这些主题，并提供有关如何使其适合您的组织环境的指导。
摘录。 API系统
随着API的功能不断增长，管理正在开发的程序变得越来越重要，以便使整个组织API的收益和价值尽可能地增长。 您需要记住这种平衡，因为如果您从从易于使用此服务作为通用系统一部分的角度来看，使用API提供单独服务的最佳（或相对较好）方法可能根本没有那么有用。
就API的总数以及新服务使用的API数量而言，现代API系统一直在不断增长。 鉴于相互依赖性的增加，我们知道，如果新服务的开发人员不必了解完全不同的API设计并应用它们，这将很有用。 差异可能是巨大的，例如，API是使用REST还是面向事件的样式（请参见第4章的“介绍支柱”部分的“设计”部分），但是即使样式匹配，也可以检测到诸如JSON格式之类的差异。或XML。
从API用户的角度来看，使用通用术语也很有用。 例如，如果您使用多个以任何形式提供用户数据的API，如果它们都具有一个主用户模型，将更加容易（即使其呈现方式略有不同，但是为不同的服务提供通用模型还是很有用的） 。
标准化带来的好处的思想清楚地表明，标准化程度越高越好。 在某种程度上是这样，但是同时也知道标准化需要时间和资源，它通常不能归结为“唯一的最佳模型”，而只是创建一个每个人都能以某种方式达成共识的模型，因此，这项投资通常具有风险和优势。
也许对每个API使用唯一格式并不是最佳解决方案，而是从现有的（例如JSON或XML）中进行选择更为合理。 在这种情况下，应用现有标准的好处超过了独特格式可能带来的好处。 但是，标准化不同服务的某些元素（例如，已经提到的用户模型）可能非常昂贵。 在这种情况下，为了找到唯一的真实用户模型而只是停止在域模型上，不花这些不合理的费用是合乎逻辑的。
一般而言，理想情况下，对于每种服务，我们都不想在不需要时重新发明轮子，而是要重用那些可减少创建设计，理解和实施的资源成本的设计元素。 如果我们能达到或至少达到理想的重用水平，这将使服务创建者可以专注于需要重点关注的那些设计方面，而不会因已经解决的问题而分心。
我们看到越来越多的组织正在这样做。 但是，最重要的是要了解并确保设计人员的手册不断更新：评估和批准新方法，淘汰旧方法，而这些更改背后的主要驱动力是组织中API方法的不断发展。
重要的是要了解API系统是一个移动且不断变化的环境，并且要使其继续工作，该体系结构必须遵循相同的持续开发路径。 然后，它就变成了一个非常大规模的系统，例如Internet，它一方面一直在工作，另一方面却在不断变化，新标准和新技术也不断出现。
考古API
尽管我们现在看到大量组织刚刚开始使用API创建程序，但重要的是要记住，在任何使用信息技术的组织中，几乎肯定有一些API已经使用了很长时间。
根据定义，API是允许两个软件组件进行交互的任何接口。 如果您将定义缩小到对网络API的现代理解，那么该接口就是允许两个软件组件通过网络进行交互的任何接口。
在许多组织中，此类接口不被称为API，并且它们并非旨在被重用（请记住有关Jeff Bezos著名API宪章的故事，我们在第3章“设计思维”部分的“ Bezos宪章”小节中讲述了这一故事）。 但是，即使创建和仅将这些接口用于单一用途的集成，通常也会存在这些接口（这会破坏API的这一主要有用属性-重用的可能性）。
查找和应用此类原始API可能很有用，因为它显示了集成需求的出现位置（即使它是使用不符合API目标的方法创建的）。 并非所有这些原始API都应被常规API取代，而仅通过了解历史，您就可以了解如何观察到集成需求，在该领域做了什么以及可能需要进行其他集成的想法。
PROTO API
在由单独的零件组成的所有复杂系统中都存在组件交互的需求。 API是执行此操作的一种方法，但还有许多其他方法。 从API的角度来看，用于在组件之间交互而不是不是API的任何机制都可以被视为原始API。 在理想的系统中，使用API，所有组件的交互都会毫无例外地执行。 如果您还记得这张理想的图片，那么没有API帮助的任何交互都将成为现代化的候选者-将由API代替。 因此，无需API即可进行组件交互的任何机制都可以视为原始API。
通常，API考古学可以帮助您更好地了解API系统，即使它现在主要由原始API组成。 它为了解过去出现的集成需求提供了一个起点，并且您可以针对哪些API投资最好地解开许多用户集成的问题网络。 随着经验的积累，随着时间的流逝，用现代模型替换API出现之前创建的集成变得越来越容易。
大规模的API管理
大规模API管理是在系统级别引入通用设计与在单个API级别最大化设计选择自由之间的平衡行为。 在集中式集成（用于一致性和优化）与分散式（用于灵活性和开发）之间的选择是复杂系统中的常见问题。
- 集中式集成为我们带来了过去的典型企业IT体系结构。 主要驱动力是功能执行的标准化，以便以最小的成本提供最佳的功能。 高度集成确实可以简化优化，但同时会影响进行更改和开发最终系统的能力。
- 分权是相反的。 它是最易访问且规模最大的示例。 这里的主要驱动力是对功能的访问的标准化，因此您可以通过不断发展的许多不同方式来提供它们。 同时，功能仍然可用，因为访问基于功能交互的一般协议。 分权化的主要目标是削弱连贯性（ http://bit.ly/2FpcUpf ），也就是说，无需更改其他部分即可促进整个系统各个部分的更改。
分散化和执行
如果我们从基于SOAP的面向服务的体系结构的未兑现承诺中学到了一些东西，那么精心管理的执行是实现面向服务的前景的关键方面。 SOAP兑现了提供对功能的访问的承诺，但是没有处理正确管理功能执行的同样重要的任务。 因此，尽管SOAP很有用（以前不可用的功能作为服务出现），但它不能满足更灵活和不断发展的环境的需求。
管理API系统的复杂性是要记住此问题并避免SOAP陷入陷阱。 SOAP表示，只有服务的可用性很重要。 这是重要的第一步，但它不能应对功能薄弱的一致性。 API，如果您特别关注实现和部署技术，那么微服务使我们可以重新考虑对大型服务系统重要的方面以及如何创建不属于SOAP陷阱的系统。
平台原理
许多人谈论平台，讨论API和主要业务目标。 但是，它们可能意味着完全不同的事情。 重要的是要记住：如果在业务级别上创建一个东西作为平台似乎是个好主意，这并不意味着应该在技术级别上进行开发。
在业务级别上，该平台提供了一些可以在其上进行构建的东西，我们不能比这个模糊的措辞更深入。 通常，“平台”概念的吸引力受到两个主要因素的影响。
- 平台覆盖率是多少？ 也就是说，通过在此平台上创建内容可以达到多少用户？ 通常，这取决于用户或订户的数量。 通常，这是最重要的参数，由总数或使用确定合适用户的定性因素计算得出，此平台可以覆盖这些参数。
- 这个平台有什么功能？ 如果您在上面创建某些东西，它将如何帮助您或限制您的收入？ 在理想情况下又不损害用户的情况下，更改平台以添加新功能是否也很容易？
这些参数对业务非常重要，但是通常会忘记一个因素：平台始终会强迫用户遵守某些限制，但是它们以不同的方式来做到这一点。 这里有一些例子。
- 符合基本网络标准的任何人都可以使用Web应用程序。 在最简单的情况下，这是具有脚本支持的现代浏览器。 任何人都可以创建它们并打开对它们的访问权限，任何人都可以使用它们。 没有控制Web平台操作的中央元素。
- Apple App Store上的应用程序在外观上与Web应用程序相似，但是提供和使用的方式完全不同。 它们只能从App Store下载，因此Apple有权决定用户可以安装什么。 此外，它们只能在iOS设备上运行，也就是说，苹果在能够使用这些应用程序的设备的销售方面拥有垄断地位。 App Store中的应用程序是专门为iOS环境创建的，也就是说，其创建投资仅受此平台的限制。 要在包括Internet在内的任何其他平台上使用该应用程序，必须在不同的开发环境中甚至使用不同的编程语言来复制该应用程序，这意味着：必须从头开始重新创建该应用程序的客户端。
您可以将此模板应用于API系统和为应用程序创建API平台的想法。
有时，API平台是指提供对API的访问的特定环境。 很快，它开始有点类似于传统的企业服务总线，在传统的企业服务总线上，类似的平台应提供基础结构，并且由于可以使用API，因此可以访问API。
在其他情况下，当谈到API平台时，它们表示服务使用和提供的一组通用原则。 在这种情况下，如果服务成为平台的一部分，则与在何处以及如何对其进行访问无关。 如果服务遵循相同的原理，协议和模板，则它们将在此平台上提供API，从而成为API系统的一部分。
第二种平台更抽象，但同时具有更多功能。 分开执行什么功能以及如何执行功能，可以促进用户对平台的贡献。 它还为创新开辟了许多途径，使应用程序可以在不影响其对API系统做出贡献的能力的情况下试验实现方法。
再以互联网为例。 如果仅从API的角度看，它会随着时间的变化而变化很大。 例如，内容传送网络（CDN）并未集成到Internet本身。 由于Internet内容的复杂性和浏览器的灵活性，使得它的存在成为可能，这使您可以根据可能来自不同地方的多种来源生成网页。 可能有人争辩说，创建CDN的潜力已经在最初的网页的原理和协议中存在，但是CDN模板只有在它出现时才出现。
适应API系统所需的新任务的能力就是这种能力。 我们基于开放和可扩展的原则和协议设计系统，但是我们可以并且希望在必要时进行更改。 我们还将创建支持模板，以帮助应用程序更有效地解决问题，并且我们希望随着时间的推移开发这些模板。
原理，协议和模板
上一部分的主要结论是：平台不应要求一种特定的方式来做某事（回答“如何？”问题），也不需要一种特定的位置（对“何处？”问题的回答）。 为持续发展的架构创建了一个好的平台，也就是说，平台的架构（而不仅仅是产品的架构）在不断发展，并且并非一次开发全部，因此在其存在的所有时间里都保持不变。
持续的架构开发
持续的体系结构开发是一种用于持续发展产品体系结构基础的方法。 使用现有体系结构框架创建单个产品，并且有关这些框架的应用程序的报告可以改善产品体系结构，从而使其效率更高。
灵活的开发方法和DevOps致力于改善单个产品的开发。 他们没有谈论如何改进此过程的基础，以便更有效的系统体系结构对产品体系结构有用。 在现有系统的工作环境中创建单个产品时，就会进行持续开发。 该系统使创建新产品变得容易，并且它们可以帮助系统找到需要改进的地方，从而创建反馈循环。
持续的体系结构开发侧重于开发不会损害现有产品并允许创建产品组合的框架。 理想情况下，体系结构的基础不断发展，以便与以前的版本兼容，因此系统的操作几乎不会受到干扰。
为了使连续的体系结构开发成为可能，该平台必须建立在原理，协议和模板上。 我们可以通过Web平台说明这一点。 众所周知，互联网是同时稳定和灵活的。 在过去的30年中，它的基本体系结构没有改变，但是当然有了显着的发展。 这种明显的矛盾如何成为可能？ 毕竟，其他系统沿着不那么激进的轨迹运动时，遇到问题的速度要快得多。
主要原因之一是Internet上没有任何内容显示特定服务是如何实现或激活的。 服务可以用任何一种语言来实现，并且随着时间的推移，它们当然会发生变化，因为编程语言也会发生变化。 可以使用任何工作环境来提供它们-最初是位于地窖中的服务器，现在位于Internet本身，最近还出现了云存储。 服务可以被任何客户端程序使用-它们也已经从简单的命令行浏览器到现代手机上的复杂图形浏览器发生了巨大变化。 完全专注于确定信息如何被识别，交换和展示的接口，事实证明，与我们所见过的任何复杂IT系统相比，Internet的体系结构都更适合自然增长。 原因很简单。
- 原则是建立在平台基础之上的基本概念。 对于Internet，这些原理之一是资源由统一资源标识符（URI）识别，然后URI识别协议授予与这些资源交互的权限。 因此，尽管我们可以（至少在理论上）不使用HTTP即可访问Internet（从某种意义上说，我们已经在迁移，因为各地的协议都在更改为HTTPS），但很难想象没有资源也可以访问Internet。 这些原则反映在API的样式中，因为样式基于不同的基本概念。
- , . (Hypertext Transfer Protocol (HTTP)), (FTP) , WebSockets WebRTC. , , HTTP/2.
- — . , , , . — Oauth, HTTP, — . — . , Oauth, , CDN. , , , , . — , .
, . , , . , -, .
, . . , - , . , , . , , , .
API . , , , , , . API — , , .
API
API . , , . , «» API, , API, .
API .
- API (, / ) . , API RPC — , API REST .
- API . , API HTTP HTTP.
- API . , 200 HTTP ( http://webconcepts.info/concepts/http-header/ ), . API , , .
- API , API ( «» . 188). : API , API, .
, — . , — . , , . , .
API — , .
- , , , , . , .
- , , . , . , , .
. , , , .
« » - - , . XML/JSON. XML-, API JSON ( , , , ).
API API
API , , , API . , . , API! API API: «, API, API».
, , API API (, , API). API API. API ( — «» « API» ), API . , .
, , , , . , API API.
, API API , . , .
. , API . , , - API.
«», «», «» «» . , , . , - , . , . , , , , , . « API» « API» 9 .
, API, API, API .
API , — , . . . — , .
, : , API, API. , , , , , , , API API, API API. API , , .
. , API, , , . , -, .
API API, , , , -. , : , API , , , , .
, API , : API , . : , , API, , .
— API, OAuth.io APIDays — API, . API API, , , API - . API, «API : », 2015 API « ». , - HEC API.
, API . IETF W3C. , , EMC, Siemens CA Technologies.
. API UX , API .
, , , , - . API API , , , API .
»
»
»
25% —
APIe-mail .