新書推薦：
《
能源列国志：全球能源转型和碳减排
》
售價：NT$
347.0
《
座头鲸来到香港：梁秉钧五十年诗选
》
售價：NT$
500.0
《
盐铁论 原文+注释+译文白话桓宽著 一场政治与经济的纠纷经济书籍经济理论中国古代官场政治制度经济学军事谋略辩论博弈智慧书
》
售價：NT$
347.0
《
脆弱的家庭
》
售價：NT$
347.0
《
如何让自己快速变强90天行动计划
》
售價：NT$
301.0
《
生成式人工智能：教师应用指南
》
售價：NT$
347.0
《
Elasticsearch实战（第2版）
》
售價：NT$
662.0
《
数字经济：澳门经济适度多元发展的新路径
》
售價：NT$
755.0
|
| 編輯推薦： |
编辑推荐
API的发布涉及大量工作，但这些付出不一定能获得回报。API成熟之前的过度筹划是一种浪费，而计划不充分则可能引发灾难。本书介绍了API以及API格局的成熟度模型，可以帮助你在正确的时间，针对正确的成熟度，投入正确的人力与公司资源。
敏捷和速度，健壮性和可扩展操作，如何才能平衡这两方面的需求？本书的作者从软件架构师、项目总监以及产品经理的角度展示了如何将API视为产品，通过持续的生命周期最z大化其价值。
专家推荐
“这是一本关于实施和管理API格局的实用指南。”
——Gregor Hohpe
《The Software Architect Elevator》的作者
|
| 內容簡介： |
|
本书的主要内容有：学习哪些API决策需要管治。通过API即产品（AaaP）的方式设计、部署和管理API。学习构成API产品基础的十大支柱。学习持续改进模型在API整个生命周期内管治变更的过程。探索API产品生命周期的五大阶段。深入探讨设计、构建与维护API的团队角色。学习如何管理组织发布的一系列API。
|
| 關於作者： |
|
Mehdi Medjaoui是一位企业家，API思维方式的倡导者。apidays会议系列、OAuth.io以及数据保护API平台ALIAS的创始人。Erik Wilde主要从事API技术以及战略，帮助各个组织有效地使用API。他创作了很多文章、书籍和视频，并长期坚持为API的标准化做贡献。Ronnie Mitra是Publicis Sapient的战略顾问，负责帮助技术领导者实现人员以及技术投资的潜力。Mike Amundsen是一位国际知名的作家和演说家，就网络架构、网络开发以及技术与社会的交集，向世界各地的组织提供咨询。
|
| 目錄：
|
目录
序 .1
前言 .3
第1 章 API 管理的挑战 9
1.1 什么是API 管理 11
1.1.1 API 业务 . 11
1.1.2 什么是API 13
1.1.3 不仅仅是API 15
1.1.4 API 的成熟度阶段 . 16
1.1.5 不止单个API 17
1.2 为什么API 管理如此之难 17
1.2.1 范围 18
1.2.2 规模 20
1.2.3 标准 20
1.3 管理API 格局 21
1.3.1 技术 22
1.3.2 团队 23
1.3.3 管治 24
1.4 小结 25
第2 章 API 管治 27
2.1 API 管治概述 . 28
2.1.1 决策 28
2.1.2 决策管理. 29
2.1.3 管治复杂的系统 . 30
2.2 决策的管治 . 33
2.2.1 集中式与分散式 . 34
2.2.2 决策元素. 40
2.2.3 决策映射. 46
2.2.4 实践中的决策设计 . 48
2.3 设计管治系统 49
2.3.1 管治模式1：设计权威 50
2.3.2 管治模式2：下放集中式专家组 52
2.3.3 管治模式3：受影响的自治 54
2.4 实施管治模式 55
2.4.1 不断改进解决方案 . 55
2.4.2 可观察性和可见性 . 57
2.4.3 运营模式. 57
2.4.4 为标准管理制定战略 58
2.5 小结 58
第3 章 API 即产品 60
3.1 可编程经济以API 为主导 61
3.2 设计思维 64
3.2.1 满足用户的需求 . 64
3.2.2 商业战略可行性 . 65
3.2.3 贝索斯命令 66
3.2.4 将设计思维应用到API 67
3.3 客户引导 69
3.3.1 惊喜时刻. 70
3.3.2 API 的客户引导 72
3.4 开发者体验 . 74
3.4.1 了解受众. 75
3.4.2 安全轻松地使用API 81
3.4.3 为什么开发人员在API 经济中如此重要 84
3.4.4 API 即产品（AaaP）的开发者关系 . 86
3.4.5 API 即产品的盈利与计价方式 . 96
3.5 小结 99
第4 章 API 产品的支柱 101
4.1 十大支柱简介 . 102
4.1.1 战略 103
4.1.2 设计 106
4.1.3 文档 111
4.1.4 开发 114
4.1.5 测试 117
4.1.6 部署 121
4.1.7 安全 124
4.1.8 监控 129
4.1.9 发现 131
4.1.10 变更管理 133
4.2 结合API 的各大支柱 135
4.2.1 将支柱应用到计划中 . 135
4.2.2 创建API 所需的四大支柱 138
4.2.3 API 运维的几大支柱 142
4.3 小结 . 146
第5 章 API 的持续改进 147
5.1 持续管理变更 . 148
5.1.1 增量式改进 . 149
5.1.2 API 变更的速度 154
5.2 API 的变更 156
5.2.1 API 发布的生命周期 156
5.2.2 接口模型的变更 158
5.2.3 实施的变更 . 160
5.2.4 实例的变更 . 161
5.2.5 支持资产的变更 162
5.3 提高API 的可变性 162
5.3.1 API 变更的成本 163
5.3.2 机会成本 163
5.3.3 耦合成本 164
5.3.4 预先做大量设计 166
5.4 小结 . 167
第6 章 API 风格 168
6.1 API 是语言 169
6.2 五大API 风格 . 171
6.2.1 隧道风格 171
6.2.2 资源风格 173
6.2.3 超媒体风格 . 175
6.2.4 查询风格 177
6.2.5 基于事件的风格 178
6.2.6 如何选择API 的风格与技术 . 180
6.3 不要局限于某种API 风格 182
6.4 小结 . 183
第7 章 API 产品的生命周期 . 184
7.1 度量与里程碑 . 185
7.1.1 OKR 和KPI 186
7.1.2 定义API 的目标 187
7.1.3 找出可度量的结果 189
7.2 API 的产品生命周期 191
7.2.1 第一个阶段：创建 192
7.2.2 第二个阶段：发布 195
7.2.3 第三个阶段：实现 200
7.2.4 第四个阶段：维护 203
7.2.5 第五个阶段：退役 205
7.3 通过产品生命周期管理各个支柱 . 208
7.3.1 创建 209
7.3.2 发布 213
7.3.3 实现 217
7.3.4 维护 219
7.3.5 退役 220
7.4 小结 . 221
第8 章 API 团队 222
8.1 API 角色 224
8.1.1 业务角色 225
8.1.2 技术角色 227
8.2 API 团队 229
8.2.1 团队与API 成熟度 . 230
8.2.2 扩展团队 237
8.2.3 Spotify 的团队与角色 238
8.2.4 影响团队扩展的因素 . 240
8.3 文化与团队 242
8.3.1 康威定律 243
8.3.2 邓巴数 245
8.3.3 亚历山大的文化马赛克 247
8.3.4 支持实验 249
8.4 小结 . 251
第9 章 API 格局 253
9.1 API 考古 255
9.2 大规模的API 管理 257
9.2.1 平台原则 258
9.2.2 原则、协议与模式 260
9.2.3 API 格局的语言格局 262
9.2.4 API 的API 264
9.3 理解API 格局 . 266
9.4 API 格局的八个V. 267
9.4.1 多样性 268
9.4.2 术语 269
9.4.3 规模 274
9.4.4 速度 275
9.4.5 脆弱性 276
9.4.6 可见性 277
9.4.7 版本管理 278
9.4.8 波动性 280
9.5 小结 . 281
第10 章 API 格局之旅. 282
10.1 构建API 格局的指南 283
10.2 API 格局指南的生命周期 287
10.3 支持中心 . 288
10.4 成熟度与八个V 292
10.4.1 多样性 293
10.4.2 术语 . 295
10.4.3 规模 . 298
10.4.4 速度 . 300
10.4.5 脆弱性 302
10.4.6 可见性 305
10.4.7 版本 . 307
10.4.8 波动性 309
10.5 小结 311
第11 章 持续发展格局中API 生命周期的管理 312
11.1 在实践中管理不断发展的格局 313
11.1.1 确立“红线” . 313
11.1.2 平台重于项目 . 314
11.1.3 设计需要考虑到消费者、生产者和赞助者 315
11.1.4 测试、衡量并吸取经验 . 317
11.2 API 产品与生命周期支柱 318
11.2.1 API 格局 319
11.2.2 决策点与成熟度 . 319
11.3 格局的各个方面与API 生命周期支柱 . 320
11.3.1 战略 . 321
11.3.2 设计 . 324
11.3.3 文档 . 326
11.3.4 开发 . 330
11.3.5 测试 . 334
11.3.6 部署 . 339
11.3.7 安全 . 344
11.3.8 监控 . 347
11.3.9 发现 . 350
11.3.10 变更管理 . 354
11.4 小结 357
第12 章 持续的旅程 359
12.1 为将来做准备 361
12.2 从今天开始管理 361
|
| 內容試閱：
|
|
前言欢迎您阅读本书的第二版，第一版的开头指出：随着社会和企业的数字化程度越来越高，互联软件的需求呈现出了爆炸式增长。另外，应用程序编程接口（Application Programming Interface，API）已成为现代组织的重要资源，因为它促进了软件之间的相互连接。但事实证明，有效管理这些API 是一项新挑战。为了获取API 的最大价值，我们需要学习如何管理API 的设计、开发、部署、增长、质量以及安全，同时还需要应对大环境、时间和规模等复杂因素。在第一版出版后的这段时间里，API 管理的发展和挑战并没有太大变化。好消息是，自第一版出版以来，我们发现了更多对API 管理发展有帮助且成熟的工具、培训和经验。不太好的消息是，我们仍然看到许多组织在努力满足相关人员、服务和公司的需求。在第二版中，我们将提供有关公司如何发展的最新信息，分享一些新的成功案例，并完善第一版的部分内容。虽然我们添加了一些新示例，并更新了已有示例，但基本方法和大纲仍然相同。希望这些变化能够帮助你充实持续API 管理的旅程。本书面向的读者如果你刚开始构建API 程序，而且想了解一下后面的工作，或者你已拥有API 但想学习一下如何更好地管理它们，则本书非常适合你。在本书中，我们会尝试构建一个可应用于多种环境的API 管理框架。书中提供的指导不仅可以帮助你管理与世界各地的开发人员共享的一个API，而且还可以就如何在专门为内部开发人员设计的微服务架构中构建一组复杂的API 提供建议，以及介于二者之间的一切。本书的编写尽可能保持技术中立。我们提供的建议和分析适用任何基于API的架构，包括 HTTP、CRUD、REST、GraphQL 以及事件驱动的交互风格。本书适合任何希望改进API 相关决策的工作人员。本书内容提要本书包含了多年来我们在设计、开发和改进 API 方面积累的知识，既囊括了我们自己的知识，也借鉴了他人的经验。我们将所有这些经验提炼到了这本书中。我们确立了有效开发API 的两个核心因素：采用产品视角与建立正确类型的团队。我们还确立了管理该工作的三个基本因素：管治、产品成熟度与格局设计。API 管理的这五个要素构成了成功构建API 管理程序的基础。在本书中，我们会逐个介绍这些主题，并提供有关如何根据组织的大环境塑造这五个要素的指导。大纲本书所讨论的管理问题的范围会随着章节的推进而逐步扩大。首先，我们介绍基于决策的管治和API 即产品的基本概念。接着，我们介绍构建API 产品必须管理的所有工作。在介绍完单个API 的管理之后，我们将深入API 随着时间发生的变化，以及API 的成熟度带给这些变更决策的影响。接下来是对执行变更工作的团队和人员的探索。最后，在本书的后半部分，我们将介绍规模的复杂性以及管理API 产品格局的挑战。下面是每章的内容概要：? 第 1 章 API 管理的挑战：介绍 API 管理域，并解释为什么有效管理 API如此困难。? 第 2 章 API 管治：从基于决策的工作（API 管理的基本概念）的角度探索管治。? 第 3 章 API 即产品：确立 API 即产品的观点，并说明为什么该观点是所有API 战略的重要组成部分。? 第 4 章 API 产品的支柱：概述 API 产品领域的十大基本支柱。这些支柱形成了一组必须加以管理的决策制定任务。? 第 5 章 API 的持续改进：深入探讨 API 持续变更的意义，以及采用持续变更思维的必要性，并带你了解不同类型的 API 变更（及其影响）。? 第 6 章 API 风格：第二版新添加的一章，探索我们在访问世界各地的公司时最常遇到的五种API 风格，并深入探索每种风格的优缺点，以帮助你选择最适合的风格。? 第 7 章 API 产品的生命周期：介绍 API 产品的生命周期框架，并帮助你在API 整个生命周期内通过十大支柱管理API。? 第 8 章 API 团队：讨论 API 管理系统中人的因素，探索 API 团队在 API产品整个生命周期内担负的常见角色、责任以及设计模式。? 第 9 章 API 格局：介绍 API 管理中的规模问题。介绍八个 V，即多样性、术语、规模、速度、脆弱性、可见性、版本以及波动性，当多个API 同时发生变化时你必须注意这些问题。? 第 10 章 API 格局之旅：概述持续格局设计方式，可用于持续、大规模地管理API 变更。? 第 11 章持续发展格局中 API 生命周期的管理：将格局视角映射回 API 即产品的视角，并说明当周围的格局发生变化时，API 工作的变化。? 第 12 章持续的旅程：总结 API 的管理工作，并提出相关建议，帮助大家为未来做好准备，踏上新征程。本书不包含的内容API 管理的范围非常广，而且在环境、平台和协议方面也存在着大量差异。由于创作的时间和空间有限，我们不可能介绍所有与API 工作相关的具体实施实践。本书不是设计REST API 或选择安全网关产品的指南。如果你正在寻找编写API 代码或设计HTTP API 的规范指南，那么这本书也不适合你。虽然书中讨论了具体的实践示例，但本书的重点不在于实施（有大量书籍、博客和视频可满足这方面的需求）。本书解决了一些鲜有人重视的问题，即如何在一个复杂的、不断变化的组织系统中有效地管理API 的构建工作。排版约定本书使用了下述排版约定。斜体（Italic）表示新术语、URL、电子邮件地址、文件名和扩展名。等宽字体（Constant Width）表示程序片段，以及正文中出现的变量、函数名、数据库、数据类型、环境变量、语句和关键字等。等宽斜体（constant width italic）表示应该由用户输入的值或根据上下文确定的值替换的文本。O’Reilly 在线学习平台（O’Reilly Online Learning）近40 年来，O’Reilly Media 致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。O’Reilly 的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境，以及O’Reilly 和200 多家其他出版商提供的大量文本和视频资源。有关的更多信息，请访问http://oreilly.com。意见和疑问请把你对本书的意见和疑问发给出版社：美国：O’Reilly Media， Inc.1005 Gravenstein Highway NorthSebastopol， CA 95472中国：北京市西城区西直门南大街2号成铭大厦C座807室（100035）奥莱利技术咨询（北京）有限公司如果你对本书有一些评论或技术上的建议， 请发送电子邮件到bookquestions@oreilly.com。要了解O’Reilly 的图书和培训课程的新闻和信息，请访问我们的网站：http://www.oreilly.com。我们的Facebook：http://facebook.com/oreilly。我们的Twitter：http://twitter.com/oreillymedia。我们的Youtube：http://youtube.com/oreillymedia。致谢本书得以付梓，我们要感谢在为第二版收集新材料的过程中，给予过帮助和支持的所有人。首先，感谢我们采访和咨询过的所有人，以及参加过线上以及线下研讨会的所有人。我们获得了积极的反馈和的良好建议。其次，还要感谢NGINX 的同仁，感谢你们鼓励我们编写第二版，并支持我们的工作。特别感谢阅读我们早期的草稿，并帮助我们完成了本书的所有人。感谢James Higginbotham、Hibri Marzook、Marjukka Niinioja 和Matthew Reinbold 在百忙之中抽出时间阅读和审查我们的创作，并指出有待提升的地方。最后，感谢O’Reilly Media 的团队。感谢Melissa Duffield、Gary O’Brien、Kate Galloway、Kim Wimpsett 以及O’Reilly 全体员工，感谢你们为本书所付出的一切努力。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 聯絡我們
| 運費計算
| 幫助中心 |
加入書簽
HOME
新書上架
