《精通API架构：设计、运维与演进 [英]詹姆斯·高夫》[97]百度网盘|亲测有效|pdf下载

书籍详情

精通API架构：设计、运维与演进 [英]詹姆斯·高夫
出版社:机械工业出版社
作者:[英]詹姆斯·高夫 ,[英]丹尼尔·布莱恩特 ,[英]马修·奥本
出版时间:2024-07-16
热度:2514
上架时间:2025-03-08 06:13:50
价格:0.0

书籍下载

点击下载

书籍预览

查看链接

免责声明

本站支持尊重有效期内的版权/著作权,所有的资源均来自于互联网网友分享或网盘资源，一旦发现资源涉及侵权，将立即删除。希望所有用户一同监督并反馈问题，如有侵权请联系站长或发送邮件到ebook666@outlook.com,本站将立马改正

内容介绍

产品特色

编辑推荐

大多数联网的组织都在构建和运维 API，这是客户开始与公司服务交互的门户。设计、构建和管理这些关键程序会影响组织中从工程师和产品所有者到最高管理层的每一个人。但开发人员和解决方案架构师面临的真正挑战是从头开始创建 API 平台。通过本书，你将学习构建和测试 REST API 的策略，这些REST API 使用 API 网关在微服务级别组合产品。三位作者解释了如何通过基础架构微调帮助工程师团队和组织平滑迁移到云，并创造使用服务网格等技术连接内部服务的机会。通过阅读本书，你将：·学习构建 API 平台的 API 基础知识和架构模式。 ·使用实际示例来了解如何设计、构建和测试基于 API 的系统。·部署、运维和配置 API 平台的关键组件。·根据案例研究合理使用 API 网关和服务网格。·了解 API 架构中的核心安全性和常见漏洞。·使用威胁建模以及 OAuth2 和 TLS 等技术保护数据和 API。·了解如何将现有系统向 API 和云架构演进。

内容简介

本书分为四部分，共十章，提供了关于设计、运维和演进API架构的全景图。本书以一个虚拟的案例贯穿始终，即如何通过小步快跑的策略，将一个用三层架构方式设计的传统应用系统迭代为一个基于API的现代架构。全书囊括了从设计、测试、运维、安全、部署和发布等整个软件生命周期的各个环节，其中第一部分介绍API的设计、构建和测试，第二部分介绍如何开展API流量管理，第三部分阐述API运维、发布和安全管理之道，第四部分介绍API架构的迭代演进，本书内容贴近实践，易于理解和应用。

作者简介

James Gough是摩根士丹利的杰出工程师，Java Champion，也是Optimizing Java一书的合著者。
Daniel Bryant是Ambassador Labs的开发者关系主管，也是Java Champion。他的专长是DevOps工具、云/容器平台和微服务。
Matthew Auburn是摩根士丹利的副总裁。他曾从事金融系统、移动和 Web 应用程序以及 API 安全方面的工作。

目　　录

目录
序1
前言3
第0章导论11
0.1 架构之旅11
0.2 API简介12
0.3 真实示例：会议系统案例研究13
0.3.1 会议案例研究中的 API 类型14
0.3.2 改进会议系统的原因15
0.3.3 从分层架构到API建模15
0.3.4 案例研究：演进步骤15
0.3.5 API 基础设施和流量模式17
0.3.6 会议系统案例研究的路线图17
0.4 使用C4图表18

目录 序1 前言3 第0章 导论11 0.1 架构之旅11 0.2 API简介12 0.3 真实示例：会议系统案例研究13 0.3.1 会议案例研究中的 API 类型14 0.3.2 改进会议系统的原因15 0.3.3 从分层架构到API建模15 0.3.4 案例研究：演进步骤15 0.3.5 API 基础设施和流量模式17 0.3.6 会议系统案例研究的路线图17 0.4 使用C4图表18 0.4.1 C4上下文关系图18 0.4.2 C4容器图18 0.4.3 C4 组件图18 0.5 使用架构决策记录19 0.5.1 参会者演进ADR20 0.5.2 精通API：ADR指南20 0.6 小结21 第一部分 设计、构建和测试API 第1章 设计、构建和规范API25 1.1 案例研究：设计参会者API25 1.2 REST介绍26 1.2.1 通过示例介绍REST和HTTP26 1.2.2 Richardson成熟度模型27 1.3 RPC API介绍28 1.4 GraphQL简要介绍29 1.5 REST API标准和结构29 1.5.1 集合和分页31 1.5.2 过滤集合32 1.5.3 错误处理32 1.5.4 ADR指南：选择API标准33 1.6 使用OpenAPI规范定义REST API33 1.7 OpenAPI规范的实际应用34 1.7.1 代码生成34 1.7.2 OpenAPI验证34 1.7.3 示例和模拟35 1.7.4 检测变更35 1.8 API版本控制35 1.8.1 语义化版本控制36 1.8.2 OpenAPI规范和版本控制37 1.9 用gRPC实现RPC38 1.10 交互建模和API格式选择40 1.10.1 高流量服务40 1.10.2 大尺寸交互负载40 1.10.3 HTTP/2的性能优势41 1.10.4 旧格式处理41 1.11 指南：交互建模41 1.12 同时使用多个规范42 1.12.1 是否存在黄金规范42 1.12.2 合并规范的挑战43 1.13 小结43 第2章 API接口测试45 2.1 本章的会议系统场景46 2.2 测试策略46 2.2.1 测试四象限47 2.2.2 测试金字塔48 2.2.3 用于测试策略的ADR指南50 2.3 契约测试50 2.3.1 契约测试的益处51 2.3.2 契约的实现方式51 2.3.3 ADR指南：契约测试55 2.4 API组件测试56 2.4.1 契约测试和组件测试的比较57 2.4.2 案例研究：用组件测试进行验证57 2.5 API集成测试58 2.5.1 使用存根服务器的好处和方法59 2.5.2 ADR指南：集成测试60 2.5.3 容器化测试组件：Testcontainers61 2.5.4 案例研究：使用Testcontainers验证集成61 2.6 端到端测试62 2.6.1 自动化端到端验证63 2.6.2 端到端测试的类型64 2.6.3 ADR指南：端到端测试64 2.7 小结65 第二部分 API流量管理 第3章 API网关：入口流量管理69 3.1 API网关是唯一解决方案吗69 3.2 指南：代理、负载均衡器或API网关70 3.3 案例研究：向消费者提供参会者服务71 3.4 什么是API网关71 3.5 API网关能提供哪些功能72 3.6 在哪里部署API网关72 3.7 API网关如何在网络边缘与其他技术集成73 3.8 为何使用API网关74 3.8.1 减少耦合：前端和后端之间的适配器/外观75 3.8.2 简化调用方式：聚合/转换后端服务75 3.8.3 保护API免受过度使用和滥用：威胁检测和防范76 3.8.4 了解API是如何被使用的：可观测性77 3.8.5 将API作为产品进行管理：API生命周期管理78 3.8.6 商业化API：账户管理、计费和支付79 3.9 API网关的现代史80 3.9.1 20世纪90年代以后：硬件负载均衡器80 3.9.2 21世纪00年代以后：软件负载均衡器80 3.9.3 21世纪00年代中期：应用程序交付控制器81 3.9.4 21世纪10年代初：第一代API网关82 3.9.5 2015年以后：第二代API网关82 3.10 当前API网关分类83 3.10.1 传统企业网关84 3.10.2 微服务/微网关84 3.10.3 服务网格网关84 3.10.4 不同类型API网关比较84 3.11 案例研究：使用API网关改进会议系统85 3.11.1 在Kubernetes中安装Ambassador Edge Stack87 3.11.2 配置URL路径到后端服务的映射87 3.11.3 使用基于主机的路由配置映射88 3.12 部署API网关：了解和管理故障88 3.12.1 API网关成为单点故障89 3.12.2 检测问题并接管89 3.12.3 解决事故和故障89 3.12.4 防范风险90 3.13 常见的API网关实现陷阱90 3.13.1 API网关回路91 3.13.2 API网关作为ESB91 3.13.3 从上到下都是“乌龟”（API网关）91 3.14 选择API网关92 3.14.1 明确需求92 3.14.2 自建还是购买92 3.14.3 ADR指南：选择API网关92 3.15 小结93 第4章 服务网格：服务间流量管理95 4.1 服务网格是唯一解决方案吗95 4.2 指南：你应该采用服务网格吗96 4.3 案例研究：把议程功能提取成服务96 4.4 什么是服务网格98 4.5 服务网格能提供什么功能99 4.6 服务网格部署在何处100 4.7 服务网格如何与其他网络技术集成100 4.8 为何使用服务网格102
4.8 为何使用服务网格 102
4.8.1 对路由、可靠性和流量管理的精细化控制 102
4.8.2 提供透明的可观测性 105
4.8.3 强化安全性：传输安全、验证和授权 105
4.8.4 支持多语言的跨职能通信 105
4.8.5 分离入站流量管理和服务间流量管理 106
4.9 服务网格的演进历史 107
4.9.1 早年历史和动机 107
4.9.2 实现方式 109
4.10 服务网格分类法 114
4.11 案例研究：使用服务网格来实现路由、可观测性和安全性 115
4.11.1 用 Istio 进行路由选择 115
4.11.2 用 Linkerd 观测流量 117
4.11.3 用 Consul 进行网络分段 119
4.12 部署服务网格：理解并管理故障 121
4.13 常见的服务网格实施误区 121
4.13.1 服务网格作为 ESB 121
4.13.2 服务网格作为网关 121
4.13.3 太多的网络层 122
4.14 选择服务网格 122
4.14.1 明确需求 122
4.14.2 自建还是购买 122
4.14.3 检查清单：选择服务网格 123
4.15 小结 124
第三部分 API 运维与安全
第 5 章 部署和发布 API 127
5.1 分离部署和发布 127
5.1.1 案例研究：功能开关 128
5.1.2 流量管理 130
5.2 案例研究：建模会议系统的发布 130
5.2.1 API 生命周期 130
5.2.2 将发布策略映射到生命周期 131
5.2.3 ADR 指南：使用流量管理和功能开关将发布与部署分离 132
5.3 发布策略 132
5.3.1 金丝雀发布 133
5.3.2 流量镜像 134
5.3.3 蓝绿发布 135
5.4 案例研究：使用 Argo Rollouts 执行部署过程 136
5.5 监控成功和识别失败 139
5.5.1 可观测性的三大支柱 140
5.5.2 API 的重要指标 140
5.5.3 读取信号 141
5.6 有效软件发布的应用程序决策 142
5.6.1 响应缓存 142
5.6.2 应用层标头传播 142
5.6.3 协助调试的日志 143
5.6.4 考虑使用理念型平台 143
5.6.5 ADR 指南：理念型平台 143
5.7 小结 144
第 6 章 运维安全性：API 的威胁建模 145
6.1 案例研究：将 OWASP 应用于参会者 API 145
6.2 忽略外部 API 安全的风险 146
6.3 威胁建模 101 147
6.4 以攻击者思维思考 148
6.5 如何进行威胁建模 149
6.5.1 第 1 步：确定目标 149
6.5.2 第 2 步：收集正确的信息 150
6.5.3 第 3 步：分解系统 150
6.5.4 第 4 步：识别威胁—以 STRIDE 为例 150
6.5.5 第 5 步：评估威胁的风险 159
6.5.6 第 6 步：验证 162
6.6 小结 162
第 7 章 API 身份验证和授权 163
7.1 身份验证 163
7.1.1 使用令牌进行最终用户身份验证 164
7.1.2 系统对系统的认证 165
7.1.3 为什么不能将密钥和用户混用 165
7.2 OAuth2 166
7.2.1 授权服务器在 API 交互中的角色 167
7.2.2 JSON 网络令牌 167
7.2.3 OAuth2 授权的术语和机制 170
7.2.4 ADR 指南：我是否应该考虑使用 OAuth2 171
7.2.5 授权码授权 171
7.2.6 刷新令牌 175
7.2.7 基于客户端凭据的授权 175
7.2.8 其他 OAuth2 授权方式 176
7.2.9 ADR 指南：选择支持哪些 OAuth2 授权方式 176
7.2.10 OAuth2 作用域 177
7.2.11 授权执行 178
7.3 OIDC 介绍 179
7.4 SAML 2.0 181
7.5 小结 181
第四部分 使用 API 的演进架构
第 8 章 将应用程序重新设计为 API 驱动的架构 185
8.1 为何使用 API 来演进系统 185
8.1.1 提取有用抽象：加强内聚 186
8.1.2 划清领域边界：拥抱松耦合 187
8.2 案例研究：建立参会者的领域界限 188
8.3 最终状态架构选择 188
8.3.1 单体架构 188
8.3.2 面向服务的架构 189
8.3.3 微服务 189
8.3.4 函数 189
8.4 管理演进过程 190
8.4.1 明确目标 190
8.4.2 使用适应度函数 190
8.4.3 将系统分解成模块 191
8.4.4 创建 API 作为扩展的“拼接点” 193
8.4.5 识别系统内的变更杠杆点 194
8.4.6 持续交付和验证 194
8.5 用 API 演进系统的架构模式 194
8.5.1 扼杀者 195
8.5.2 外观和适配器 196
8.5.3 API 分层蛋糕架构 196
8.6 识别痛点和机会 197
8.6.1 升级和维护问题 197
8.6.2 性能问题 198
8.6.3 打破依赖性：高度耦合的 API198
8.7 小结 198
第 9 章 使用 API 基础设施向云平台演进 200
9.1 案例研究：将参会者服务迁移到云环境 200
9.2 选择云迁移策略 201
9.2.1 保留或重审 202
9.2.2 重新托管 202
9.2.3 平台化改造 203
9.2.4 重新购买 203
9.2.5 重构 / 重新架构 203
9.2.6 退役 204
9.3 案例研究：将参会者服务迁移到云平台 204
9.4 API 管理的作用 205
9.5 南北向与东西向：模糊的流量管理界限 206
9.5.1 从外向内进行迁移 206
9.5.2 跨越边界：跨网络路由 206
9.6 从区域架构到零信任架构 207
9.6.1 进入分区的世界 207
9.6.2 不信任任何人并始终验证 208
9.6.3 服务网格在零信任架构中的作用 209
9.7 小结 211
第 10 章 总结 213
10.1 案例研究：回顾 213
10.2 API、康威定律和组织机构 218
10.3 了解决策类型 219
10.4 准备好迎接未来 219
10.4.1 异步通信 219
10.4.2 HTTP/3 220
10.4.3 基于平台的网格 220
10.5 如何不断学习 API 架构 220
10.5.1 不断磨炼基本功 221
10.5.2 了解最新行业新闻 221
10.5.3 雷达、象限和趋势报告 221
10.5.4 学习最佳实践和用例 222
10.5.5 寓学于练 222
10.5.6 教学相长 223

显示全部信息

前　　言

译者序
世界是普遍联系和永恒发展的。
自IT行业诞生以来，世界始终处于快速的变革与演进之中。无论是基础设施、编程语言，还是设计思想和架构模式，都在持续迭代和完善。即使是那些使用尖端技术构建的软件系统，也可能在短时间内显得不够先进。这样的高速变化，虽然有时会让人觉得有些力不从心，但正是这种持续的进步和创新，构成了此行业的独特魅力。它意味着新机会的不断涌现、软件生态的持续改进，以及技术门槛的不断降低，为互联网时代和AI时代创造了无数可能性。
API是Application Programming Interface（应用程序编程接口）的缩写，是应用程序世界相互连接的桥梁。AWS将API定义为“两个软件组件使用一组定义和协议相互通信的机制”，IBM则将API定义为“一组定义的规则，使不同的应用程序能够相互通信”。我国金融标准化技术委员会发布的《商业银行应用程序接口安全管理规范》（JR/T 0185—2020）中则将API定义为“一组预先定义好的功能，开发者可通过该功能（或功能的组合）便捷地访问相关服务，而无须关注服务的设计与实现”。

译者序 世界是普遍联系和永恒发展的。 自IT行业诞生以来，世界始终处于快速的变革与演进之中。无论是基础设施、编程语言，还是设计思想和架构模式，都在持续迭代和完善。即使是那些使用尖端技术构建的软件系统，也可能在短时间内显得不够先进。这样的高速变化，虽然有时会让人觉得有些力不从心，但正是这种持续的进步和创新，构成了此行业的独特魅力。它意味着新机会的不断涌现、软件生态的持续改进，以及技术门槛的不断降低，为互联网时代和AI时代创造了无数可能性。 API是Application Programming Interface（应用程序编程接口）的缩写，是应用程序世界相互连接的桥梁。AWS将API定义为“两个软件组件使用一组定义和协议相互通信的机制”，IBM则将API定义为“一组定义的规则，使不同的应用程序能够相互通信”。我国金融标准化技术委员会发布的《商业银行应用程序接口安全管理规范》（JR/T 0185—2020）中则将API定义为“一组预先定义好的功能，开发者可通过该功能（或功能的组合）便捷地访问相关服务，而无须关注服务的设计与实现”。 我们综合这几个定义可以看到这个应用程序世界桥梁的真正目的和定义： 目的：用来为开发者在无须关注服务的设计与实现的情况下便捷地访问相关服务。 定义：不同的应用程序使用一组定义规则和协议相互通信的机制。 2023年初在机械工业出版社华章分社有关老师的推荐下，我们很幸运地接触到了这本书，书中用前瞻性的思维和全局视角详细阐释了当前最先进的基于API的架构设计方法和技术。其独到之处不仅在于对现有最主流技术的介绍，更在于其所采用的方法论既可以帮助读者升级和完善现有系统，也为读者应对未来变革提供了指南。其中的C4架构图、ADR和DFD等都是在大型企业架构设计中得到广泛应用的简明却功能强大的实用工具。不同于其他仅停留在理论层面的书籍，本书以一个虚拟的案例贯穿始终，即如何通过小步快跑的策略将一个用三层架构方式设计的传统应用系统迭代为一个基于API的现代架构。本书分为四部分，共10章，囊括了设计、测试、运维、安全、部署和发布等整个软件生命周期的各个环节，其中第一部分介绍API的设计、构建和测试，第二部分介绍如何开展API流量管理，第三部分阐述API运维、发布和安全管理之道，第四部分介绍API架构的迭代演进。本书内容贴近实践，易于理解和应用。此外，书中的大量引用、深度阅读链接和工具推荐，不仅彰显了三位作者的深厚学识和实战经验，更为读者提供了丰富的延伸阅读和实际操作参考。 三位作者都是资深开发人员，也各有所长—有的擅长API架构设计和实施，有的是曾获得Java Champion的Java社区的关键影响者；有的熟悉安全架构，在摩根士丹利这样的世界级投行负责系统开发—他们基于各自的理论积累和项目实践为本书做出了贡献。 当我们第一次接触这本书时，便被其内容吸引，心生将其翻译成中文的愿望，以便国内的同行能从中受益。在数月的翻译过程中，我们深刻感受到了本书的实用价值。事实上，书中的许多内容我们已经在实际工作中采纳并取得了显著的效果。 在此衷心感谢施勇、许惊皞、付晓岩、杜军、徐鸣、马成明、王劲松、马欢、黄勇、张礼立、刘安、张海涛、胡萍、贾瑞起、黄磊等15位来自云计算、应用开发、网络安全、数据管理、科技创投、电子商务等方面的前辈和专家给我们在翻译过程中和成稿后的专业意见，他们的意见为我们探索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 的系统。 解决方案架构师 / 企业架构师 你已经设计和构建企业软件系统多年，并且很可能在你的职位或角色描述中包含“架构 师”一词。你对软件交付的整体情况负责，并通常在大厂或集团公司环境中工作。
你认识到最新一代基于服务的架构风格对软件的设计、集成和治理所带来的变化，并且认为 API 对于组织的软件战略的成功至关重要。你渴望了解更多关于演进模式的内容，并渴望了解 API 设计和实施的决策将如何影响它。你还希望专注于非功能的相关“特性”，包括易用性、可维护性、可扩展性和可用性，并了解如何构建既具有上述特性又能提供安全性的基于 API 的系统。
你将学到什么
阅读本书后，你将理解以下内容：
<ul>
<li>REST API 的基础知识，以及构建、版本控制和测试 API 的最佳方法。</li>
<li>构建 API 平台所涉及的架构模式。</li>
</ul>
<ul>
<li>处理 API 入口流量和服务间流量的差异，以及如何应用 API 网关、服务网格等模式和技术。</li>
</ul>
<ul>
<li>对 API 进行威胁建模并考虑关键安全因素，如身份验证、授权和加密。</li>
</ul>
<ul>
<li>如何将现有系统向 API 架构演进并采用不同的部署方案，比如云端部署。</li>
</ul>
你还将能够：
<ul>
<li>设计、构建和测试基于 API 的系统。</li>
</ul>
<ul>
<li>从架构的角度帮助实施和推动组织的 API 计划。</li>
</ul>
<ul>
<li>部署、发布和配置 API 平台的关键组件。</li>
</ul>
<ul>
<li>根据案例研究部署网关和服务网格。</li>
</ul>
<ul>
<li>识别 API 架构中的漏洞，并实施有针对性的安全防范措施。</li>
</ul>
<ul>
<li>投入最新的 API 技术趋势研究并参与相关技术社区的发展。</li>
</ul>
本书不包含什么
我们意识到 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 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，他是我最大的快乐源泉。

显示全部信息

相关推荐