大多数联网的组织都在构建和运维 API，这是客户开始与公司服务交互的门户。设计、构建和管理这些关键程序会影响组织中从工程师和产品所有者到最高管理层的每一个人。但开发人员和解决方案架构师面临的真正挑战是从头开始创建 API 平台。通过本书，你将学习构建和测试 REST API 的策略，这些REST API 使用 API 网关在微服务级别组合产品。三位作者解释了如何通过基础架构微调帮助工程师团队和组织平滑迁移到云，并创造使用服务网格等技术连接内部服务的机会。通过阅读本书，你将：·学习构建 API 平台的 API 基础知识和架构模式。 ·使用实际示例来了解如何设计、构建和测试基于 API 的系统。·部署、运维和配置 API 平台的关键组件。·根据案例研究合理使用 API 网关和服务网格。·了解 API 架构中的核心安全性和常见漏洞。·使用威胁建模以及 OAuth2 和 TLS 等技术保护数据和 API。·了解如何将现有系统向 API 和云架构演进。
James Gough是摩根士丹利的杰出工程师，Java Champion，也是Optimizing Java一书的合著者。
Daniel Bryant是Ambassador Labs的开发者关系主管，也是Java Champion。他的专长是DevOps工具、云/容器平台和微服务。
Matthew Auburn是摩根士丹利的副总裁。他曾从事金融系统、移动和 Web 应用程序以及 API 安全方面的工作。
10 多年前，当我在英国《金融时报》构建第一个 API 时，并没有那么多API。我们实现 的是单体架构，API 仅供外部第三方访问我们的内容。
然而现在，API 无处不在，它们是成功构建系统的核心。
这是因为，在过去的 10 年里，有几件事结合在一起改变了软件开发的方式。
首先，我们可用的技术发生了变化。云计算的兴起为我们提供了自助式、按需配置的服 务。自动化构建和部署管道使我们能够进行持续集成和部署，容器及其相关技术（如编 排）让我们能够在分布式系统中运行大量小型、独立的服务。
为什么我们要那么做？因为研究表明，成功的软件开发组织具有松耦合的架构和独立自 主的团队。这里的“成功”是指对企业产生积极影响：增加市场份额、改进生产效率和 提升盈利能力。
现在的架构往往更加松耦合、分布式，并且围绕 API 构建。你希望 API 易于发现、有较 强一致性且不会给消费者带来问题，即使消费者执行了意外操作或彻底离开。任何其他 解决方案都会将工作耦合在一起，减缓团队的开发速度。
在这本书中，James 、Daniel 和 Matthew 提供了一份全面且实用的指南，教你如何构建 高效的 API 架构。内容涵盖多个领域，从如何构建和测试单个 API 到如何部署它们的生 态系统，以及如何对它们进行有效的发布和运维，最重要的是如何使用 API 来演进你的 架构。我在《金融时报》构建的第一批 API 已经不存在了，我们从头开始重新构建了那 些系统。那样做代价不菲，James 、Daniel 和 Matthew 提供了一个模板，教你如何应对 不可避免的变化，并使用 API 作为关键工具来演进你的系统。
软件架构被定义为那些既重要又难以改变的决策。这些决策将决定你项目的成败。
作者的关注点不是抽象的架构，而是如何在你自己的组织中应用架构。决定采用 API 网
关还是服务网格，以及具体选择哪一款产品，都是你应该谨慎对待并仔细评估的难以回 退的决策。James 、Daniel 和 Matthew 在他们认为适当的地方给出了明确的、有见地的 指导，而在不太明确的地方，他们提供了一个框架来帮助你根据自己的情况做出最佳 选择。
他们用一个实用的现实案例研究来说明概念，并展示如何在实践中真正运用这些概念。 该案例研究在整本书中不断演进，就像真实的系统一样。作者通过这种方式说明你不必 一开始就把所有工作都做好，而是可以逐步演进你的架构，逐步提取服务，并在需要时 添加 API 网关和服务网格等工具。
我在构建第一个 API 时犯了很多错误。我希望当时有这样一本书，能帮助我了解自己可 能会在哪里犯错，并引导我做出明智的决策。
我向任何在以 API 为核心的系统上担任领导工作的人推荐这本书。有了它，你将能够为 组织中的每个 API 构建团队开发一套标准化的工具和规范。
—Sarah Wells ，
QCon 伦敦会议联席主席，独立顾问，前《金融时报》技术总监， 2022 年 9 月于英国雷丁
前言
我们为什么要撰写本书
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 的系统。
解决方案架构师 / 企业架构师
你已经设计和构建企业软件系统多年，并且很可能在你的职位或角色描述中包含“架构 师”一词。你对软件交付的整体情况负责，并通常在大厂或集团公司环境中工作。
你认识到最新一代基于服务的架构风格对软件的设计、集成和治理所带来的变化，并且 认为 AP
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
