前言

我们为什么要撰写本书

2020年初，我们参加了纽约的O'Reilly软件架构大会，期间James和Matthew举办了一场关于API和API网关的研讨会。James和Daniel相识于伦敦Java社区，与许多有关架构的活动一样，我们聚在一起讨论对API架构的想法和理解。当我们在走廊上交谈时，有几位会议代表过来与我们交流他们在API方面的经验，也有人询问我们关于API的想法和建议。这时，我们认为撰写一本关于API主题的书有助于将我们在会议上讨论的内容与其他架构师分享。

你为什么应该阅读本书

本书旨在提供关于设计、运维和演进API架构的全景图。我们通过文字和一个配套的案例研究分享了我们的经验和建议，本书中的案例研究模拟了真实的活动管理会议系统，该系统使参会者能够查看和预订演讲会议场次。该案例研究贯穿全书，目的是让你能够将抽象的概念转化为实际的应用。如果你只想粗略地看一下这个案例研究的整个演进过程，可以直接参考第10章的内容。

我们相信允许你自行决策的重要性，为此，我们将：

●明确给出可行的建议和指导。

●强调可能遇到的注意事项和问题。

●提供一个架构决策记录（Architecture Decision Record，ADR）指南[1]，以在特定的架构情况下提供最佳决策，并提供相关考虑因素的指导（因为有时答案“因情况而异”）。

●推荐参考资料和有价值的文章，以便你深入阅读。

本书不仅是一本全新的技术书籍。我们认为，覆盖现有架构并以演进的方式逐步转向更合适的API架构，将给你带来最大的收益。同时，我们也尽可能地介绍了API架构领域中的前沿技术和对未来发展的展望。

目标读者

尽管我们在编写本书时关于目标读者已经有了一个最初的角色设想，但在写作和审校过程中还是出现了三个关键角色：开发人员、半路出家的架构师、解决方案架构师或企业架构师。我们在下文概述了这些角色，目的是希望你不仅能认同这些角色，而且还能通过这些角色所提供的不同视角来阅读每一章。

开发人员

你很可能已经有几年的专业编码经验，并对常见的软件开发挑战、模式和最佳实践有很好的理解。你越来越意识到，软件行业正朝着构建面向服务的架构（SOA）和采用云服务的方向发展，这意味着构建和运营API正迅速成为一项核心技能。你渴望了解更多关于设计有效API和测试它们的知识。你希望探索各种不同的实现方法（例如同步与异步通信）和技术，并学习如何提出正确的问题和评估不同方法的最佳使用场景。

半路出家的架构师

你很可能已经从事软件开发多年，并经常担任团队负责人或常驻软件架构师（即使没有官方职称）。你理解核心的架构概念，比如高内聚性和低耦合性的设计，并将其应用于软件开发的各个方面，包括设计、测试和运维系统。

你意识到，你的角色越来越专注于将系统组合起来以满足客户需求。这可能包括内部构建的应用程序和第三方SaaS类型的服务。API在成功地将你的系统与外部系统集成方面起着重要作用。你希望了解更多相关的支撑技术（例如API网关、服务网格等），并且还想了解如何运维和保护基于API的系统。

解决方案架构师/企业架构师

你已经设计和构建企业软件系统多年，并且很可能在你的职位或角色描述中包含“架构师”一词。你对软件交付的整体情况负责，并通常在大厂或集团公司环境中工作。

你认识到最新一代基于服务的架构风格对软件的设计、集成和治理所带来的变化，并且认为API对于组织的软件战略的成功至关重要。你渴望了解更多关于演进模式的内容，并渴望了解API设计和实施的决策将如何影响它。你还希望专注于非功能的相关“特性”，包括易用性、可维护性、可扩展性和可用性，并了解如何构建既具有上述特性又能提供安全性的基于API的系统。

你将学到什么

阅读本书后，你将理解以下内容：

●REST API的基础知识，以及构建、版本控制和测试API的最佳方法。

●构建API平台所涉及的架构模式。

●处理API入口流量和服务间流量的差异，以及如何应用API网关、服务网格等模式和技术。

●对API进行威胁建模并考虑关键安全因素，如身份验证、授权和加密。

●如何将现有系统向API架构演进并采用不同的部署方案，比如云端部署。

你还将能够：

●设计、构建和测试基于API的系统。

●从架构的角度帮助实施和推动组织的API计划。

●部署、发布和配置API平台的关键组件。

●根据案例研究部署网关和服务网格。

●识别API架构中的漏洞，并实施有针对性的安全防范措施。

●投入最新的API技术趋势研究并参与相关技术社区的发展。

本书不包含什么

我们意识到API涵盖了广阔的市场空间，因此想要明确指出本书不涵盖的内容。这并不意味着我们认为这些主题不重要。然而，如果我们试图涵盖所有内容，就无法有效地与你分享我们的知识。

我们将涵盖迁移和现代化的应用模式，包括利用云平台的优势，但“本书并不完全专注于云技术”。许多人可能拥有混合架构，甚至将所有系统托管在数据中心。我们希望所提供的API架构的设计和运维要素能够同时支持这两种平台架构的部署。

“本书不限于特定的编程语言”，但会使用一些简单的示例来演示构建/设计API及其相应基础设施的方法。本书将更加关注方法，代码示例将在附带的GitHub存储库（https://github.com/masteringapi）中提供。

本书并不偏爱某种架构风格，但我们会讨论在哪些情况下，架构方法可能会对所提供的API造成限制。

排版约定

本书中使用以下排版约定：

斜体（Italic）

表示新的术语、URL、电子邮件地址、文件名和文件扩展名。

等宽字体（Constant width）

用于程序清单，以及段落中的程序元素，例如变量名、函数名、数据库、数据类型、环境变量、语句以及关键字。

等宽粗体（Constant width bold）

表示应由用户直接输入的命令或其他文本。

等宽斜体（Constant width italic）

表示应由用户提供的值或由上下文确定的值替换的文本。

该图示表示提示或建议。

该图示表示一般性说明。

该图示表示警告或注意。

示例代码

可以从https://github.com/masteringapi下载补充材料（示例代码、练习、勘误等）。

这里的代码是为了帮助你更好地理解本书的内容。通常，可以在程序或文档中使用本书中的代码，而不需要联系O'Reilly获得许可，除非需要大段地复制代码。例如，使用本书中所提供的几个代码片段来编写一个程序不需要得到我们的许可，但销售或发布O'Reilly的示例代码则需要获得许可。引用本书的示例代码来回答问题也不需要许可，将本书中的很大一部分示例代码放到自己的产品文档中则需要获得许可。

非常欢迎读者使用本书中的代码，希望（但不强制）注明出处。注明出处时包含书名、作者、出版社和ISBN，例如：

Mastering API Architecture，作者James Gough、Daniel Bryant和Matthew Auburn，由O'Reilly出版，书号978-1-492-09063-2。

如果读者觉得对示例代码的使用超出了上面所给出的许可范围，欢迎通过permissions@oreilly.com联系我们。

O'Reilly在线学习平台（O'Reilly Online Learning）

40多年来，O'Reilly Media致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。

我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。O'Reilly的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境，以及O'Reilly和200多家其他出版商提供的大量文本和视频资源。有关的更多信息，请访问https://oreilly.com。

如何联系我们

对于本书，如果有任何意见或疑问，请按照以下地址联系本书出版商。

美国：

O'Reilly Media，Inc.

1005 Gravenstein Highway North

Sebastopol，CA 95472

中国：

北京市西城区西直门南大街2号成铭大厦C座807室（100035）

奥莱利技术咨询（北京）有限公司

要询问技术问题或对本书提出建议，请发送电子邮件至errata@oreilly.com.cn。

本书配套网站https://oreil.ly/Mastering-API-Architecture上列出了勘误表、示例以及其他信息。

关于书籍和课程的新闻和信息，请访问我们的网站https://oreilly.com。

我们在LinkedIn上的地址：https://linkedin.com/company/oreilly-media。

我们在Twitter上的地址：https://twitter.com/oreillymedia。

我们在YouTube上的地址：https://youtube.com/oreillymedia。

致谢

本书的封面上只列出了三位作者的名字，但实际上有许多人直接通过反馈对书稿的建议或间接通过多年来的教学和指导为本书做出了贡献。

虽然我们不可能列出每一个在这个过程中帮助我们的人，但我们想特别感谢那些抽出宝贵时间进行广泛讨论、提供反馈和支持的人。

我们的技术审校人员：Sam Newman、Dov Katz、Sarah Wells、Antoine Cailliau、Stefania Chaplin、Matt McLarty和Neal Ford。

提供了各种细节、鼓励、建议和介绍的人员：Charles Humble、Richard Li、Simon Brown、Nick Ebbitt、Jason Morgan、Nic Jackson、Cliff Tiltman、Elspeth Minty、George Ball、Benjamin Evans和Martijn Verberg。

O'Reilly团队成员：Virginia Wilson、Melissa Duffield和Nicole Tache。

James Gough

我想感谢我出色的家人：Megan、Emily和Anna。没有他们的帮助和支持，本书是不可能完成的。我还想感谢我的父母——Heather和Paul，因为他们一直鼓励我学习并给予我持续的支持。

我要感谢我的合著者Daniel和Matthew。写一本书是一项挑战，就像架构一样，永远都不完美。这是一段有趣的经历，我们从彼此以及我们了不起的审校人员身上都学到了很多。最后，我要感谢Jon Daplyn、Ed Safo、David Halliwell和Dov Katz在我职业生涯中给予我的支持、机会和鼓励。

Daniel Bryant

我要感谢我整个家庭对我的爱和支持，无论是在写作过程中还是在我的职业生涯中。我还要感谢James和Matthew，他们是我在写作过程中的伟大伙伴。我们在2020年初开始写这本书，之后每周三早上的电话不仅有助于合作，也是我们在迅速变化的世界中寻找乐趣和支持的重要来源。最后，我要感谢伦敦Java社区（LJC）、InfoQ/QCon团队以及Ambassador Labs的所有人。这三个社区给我提供了导师、指导建议和许多机会。我希望有朝一日能够回报这一切。

Matthew Auburn

我要感谢我了不起的妻子Hannah，没有她的支持，我就无法完成这本书。谢谢我的父母，他们向我展示了一切皆有可能，并且一直相信我。写作这本书对我来说是一次非常棒的经历，James和Daniel，他们都是出色的导师，教会了我很多东西，帮助我写出了最好的材料。特别感谢James，是他启发我开始做演讲，并且在我的职业生涯中给予了最大的帮助。最后，也是最重要的，我要感谢我的儿子Joshi，他是我最大的快乐源泉。

---

[1]在导论中，你将了解更多关于ADR及其在制定和记录架构决策中的重要性。