登入帳戶　 |　訂單查詢　 |　購物車/收銀台( 0 )　|　在線留言板　 |　付款方式　 |　運費計算　 |　聯絡我們　 |　幫助中心　|　 加入書簽
會員登入 新用戶登記
HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類瀏覽雜誌 臺灣用戶
品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心 服務：香港／台灣／澳門／海外 送貨：速遞／郵局／服務站

新書上架：簡體書 繁體書
暢銷書架：簡體書 繁體書
好書推介：簡體書 繁體書

四月出版：大陸書 台灣書
三月出版：大陸書 台灣書
二月出版：大陸書 台灣書
一月出版：大陸書 台灣書
12月出版：大陸書 台灣書
11月出版：大陸書 台灣書
十月出版：大陸書 台灣書
九月出版：大陸書 台灣書
八月出版：大陸書 台灣書
七月出版：大陸書 台灣書
六月出版：大陸書 台灣書
五月出版：大陸書 台灣書
四月出版：大陸書 台灣書
三月出版：大陸書 台灣書
二月出版：大陸書 台灣書

『簡體書』持续API管理

書城自編碼： 3728649
分類：簡體書→大陸圖書→計算機/網絡→程序設計
作者： [美]迈赫迪·梅加维，[美]埃里克·王尔德，[美]罗尼·米特
國際書號(ISBN)： 9787519863524
出版社： 中国电力出版社
出版日期： 2022-02-01

頁數/字數： /
書度/開本： 16开 釘裝： 平装

售價：HK$ 110.0

我要買 件

 

** 我創建的書架 **
未登入.

新書推薦：
最后一个人（《时代》杂志评其为“十大后世界末日小说”之一）
《 最后一个人（《时代》杂志评其为“十大后世界末日小说”之一） 》
售價：HK$ 82.8
黑海史：从历史涟漪到时代巨浪
《 黑海史：从历史涟漪到时代巨浪 》
售價：HK$ 115.2
楼边人似玉
《 楼边人似玉 》
售價：HK$ 56.2
我，毕加索
《 我，毕加索 》
售價：HK$ 60.0
投资真相
《 投资真相 》
售價：HK$ 81.6
非洲大陆简史（萤火虫书系）
《 非洲大陆简史（萤火虫书系） 》
售價：HK$ 93.6
中国龙的发明：近现代中国形象的域外变迁
《 中国龙的发明：近现代中国形象的域外变迁 》
售價：HK$ 119.8
和离：完结篇
《 和离：完结篇 》
售價：HK$ 63.4

 
建議一齊購買：

+

HK$ 98.6
《 PHP学习手册 》		 +

HK$ 115.7
《 零基础学PHP（全彩版） 》		 +

HK$ 111.3
《 Python自动化运维快速入门（第2版） 》		 +

HK$ 137.3
《 Python编程 从入门到实践 第2版（百万册纪念版） 》		 +

HK$ 142.6
《 Netty 4核心原理与手写RPC框架实战 》		 +

HK$ 143.6
《 学习HTML5（第7版） 》
編輯推薦：
API的发布涉及大量的工作，但是API成熟之前的过度筹划是一种浪费，而计划不充分则可能引发灾难。这本实用指南提供了API以及API格局的成熟度模型，可以帮助你在正确的时间，针对正确的成熟度，投入正确的人力与公司资源。
敏捷和速度，健壮性和可扩展操作，如何才能平衡这两方面的需求？本书作者从软件架构师、项目总监以及产品经理的角度展示了如何将API作为产品，通过持续的生命周期化其价值。
內容簡介：
学习哪些API决策需要管治，以及何时通过何种方法管治。通过API即产品（AaaP）的方式设计、部署和管理API。学习构成API产品基础的十大支柱。学习持续改进模型在API整个生命周期内管治变更的过程。探索API产品生命周期的五大阶段。深入探讨设计、构建与维护API的团队角色。
学习如何管理API格局（即由组织发布的一系列API）
關於作者：
Mehdi Medjaoui是API学院的首席API经济学家，OAuth.io的创始人以及2020 EU委员会的API管治专家。
Erik Wilde是API学院的首席顾问，主要从事数字化转换以及API的战略、设计和管理的工作。
Ronnie Mitra是API学院的首席设计师，专门从事高价值API、战略以及组织系统的开发工作。
Mike Amundsen是API学院的首席架构师，负责帮助各个公司发展API业务。
目錄：
目录
序 .1
前言 .3
第1 章 API 管理的挑战 9
1.1 什么是API 管理？ . 11
1.1.1 什么是API ？ 11
1.1.2 不仅仅是API 13
1.1.3 API 成熟度阶段 14
1.1.4 不止单个API 14
1.1.5 API 业务 . 15
1.2 为什么API 管理如此之难？ . 16
1.2.1 范围 17
1.2.2 规模 18
1.2.3 标准 18
1.3 管理API 格局 19
1.3.1 技术 20
1.3.2 团队 21
1.3.3 管治 22
1.4 小结 23
第2 章 API 管治 25
2.1 API 管治概述 . 26
2.1.1 决策 26
2.1.2 决策的管治 27
2.1.3 管治复杂的系统 . 28
2.2 决策的管治 . 31
2.2.1 集中式与分散式 . 33
2.2.2 决策元素. 39
2.2.3 决策映射. 44
2.3 设计管治系统 46
2.3.1 管治模式1：接口监督 48
2.3.2 管治模式2：机器驱动的管治 . 49
2.3.3 管治模式3：协作式管治 50
2.4 小结 51
第3 章 API 即产品 53
3.1 设计思维 54
3.1.1 满足用户的需求 . 55
3.1.2 商业战略可行性 . 56
3.1.3 贝索斯命令 56
3.1.4 将设计思维应用到API 57
3.2 客户引导 59
3.2.1 惊喜时刻. 60
3.2.2 API 的客户引导 62
3.3 开发者体验 . 63
3.3.1 了解受众. 64
3.3.2 安全轻松地使用API 70
3.4 小结 73
第4 章 API 产品的十大支柱 75
4.1 十大支柱简介 76
4.1.1 战略 77
4.1.2 设计 80
4.1.3 文档 84
4.1.4 开发 87
4.1.5 测试 91
4.1.6 部署 94
4.1.7 安全 98
4.1.8 监控 100
4.1.9 发现与推广 . 102
4.1.10 变更管理 104
4.2 小结 . 106
第5 章 API 的持续改进 107
5.1 API 的变更 108
5.1.1 API 发行的生命周期 109
5.1.2 接口模型的变更 110
5.1.3 实施的变更 . 113
5.1.4 实例的变更 . 113
5.1.5 支持资产的变更 114
5.2 持续变更 115
5.2.1 增量式改进 . 115
5.2.2 API 变更的速度 117
5.3 提高API 的可变性 119
5.3.1 API 变更的成本 120
5.3.2 机会成本 120
5.3.3 耦合成本 121
5.4 小结 . 123
第6 章 API 产品的生命周期 . 124
6.1 度量与里程碑 . 125
6.1.1 OKR 和KPI 126
6.1.2 定义API 的目标 127
6.1.3 可度量的结果 128
6.2 API 的产品生命周期 131
6.2.1 个阶段：创建 132
6.2.2 第二个阶段：发布 133
6.2.3 第三个阶段：实现 136
6.2.4 第四个阶段：维护 137
6.2.5 第五个阶段：退役 138
6.3 通过产品生命周期管理各个支柱 . 140
6.3.1 创建 141
6.3.2 发布 144
6.3.3 实现 148
6.3.4 维护 150
6.3.5 退役 151
6.4 小结 . 152
第7 章 API 团队 153
7.1 API 角色 155
7.1.1 业务角色 156
7.1.2 技术角色 158
7.2 API 团队 160
7.2.1 团队与API 成熟度 . 161
7.2.2 扩展团队 168
7.2.3 Spotify 的团队与角色 168
7.2.4 通过文档扩展团队 170
7.3 文化与团队 171
7.3.1 康威定律 172
7.3.2 邓巴数 174
7.3.3 亚历山大的文化马赛克 175
7.3.4 支持实验 177
7.4 小结 . 179
第8 章 API 格局 181
8.1 API 考古 183
8.2 大规模的API 管理 185
8.2.1 平台原则 186
8.2.2 原则、协议与模式 188
8.2.3 API 格局的语言格局 191
8.2.4 API 的API 192
8.3 理解API 格局 . 194
8.4 API 格局的八个V. 195
8.4.1 多样性 196
8.4.2 术语 197
8.4.3 规模 202
8.4.4 速度 203
8.4.5 脆弱性 204
8.4.6 可见性 205
8.4.7 版本 206
8.4.8 波动性 208
8.5 小结 . 209
第9 章 API 格局之旅 210
9.1 构建API 格局的指南 211
9.2 API 格局指南的生命周期 . 215
9.3 支持中心 216
9.4 成熟度与八个V . 220
9.4.1 多样性 221
9.4.2 术语 223
9.4.3 规模 226
9.4.4 速度 229
9.4.5 脆弱性 231
9.4.6 可见性 234
9.4.7 版本 237
9.4.8 波动性 239
9.5 小结 . 241
第10 章 持续发展格局中的API 生命周期管理 242
10.1 API 产品与生命周期支柱 243
10.1.1 API 格局 243
10.1.2 决策点与成熟度 244
10.2 格局的各个方面与API 生命周期支柱. 245
10.2.1 战略 . 246
10.2.2 设计 . 248
10.2.3 文档 . 251
10.2.4 开发 . 254
10.2.5 测试 . 258
10.2.6 部署 . 264
10.2.7 安全 . 268
10.2.8 监控 . 271
10.2.9 发现 . 274
10.2.10 变更管理 . 278
10.3 小结 281
第11 章 持续的旅程 . 283
11.1 为将来做准备 284
11.2 从今天开始管理 285
內容試閱：
前言
随着社会和企业的数字化程度越来越高，互联软件的需求呈现出了爆炸式增长。反过来，应用程序编程接口（Application Programming Interface，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 如此困难。
第2 章从基于决策的工作（API 管理的基本概念）的角度探索管治。
第3 章确立API 即产品的观点，以及为什么该观点是所有API 战略的重要组成部分。
第4 章概述API 产品领域的十大基本支柱。这些支柱形成了一组必须加以管理的决策制订的任务。
第5 章深入探讨API 持续变更的意义，并介绍采用持续变更思维的必要性，帮助你了解不同类型的 API 变更（及其影响）。
第6 章介绍API 产品的生命周期框架，并帮助你在API 整个生命周期内通过十大支柱管理API。
第7 章讨论API 管理系统中人的因素，探索API 团队在API 产品整个生命周期内担负的常见角色、责任，以及设计模式。
第8 章介绍API 管理中的规模问题。介绍八个“V”，即多样性、术语、规模、速度、脆弱性、可见性、版本，以及波动性，这些是当多个API 同时发生变化时必须注意的问题。
第9 章概述持续格局设计方式，可用于持续、大规模地管理API 变更。
第10 章将格局视角映射回API 即产品的视角，并说明当周围的格局发生变化时，API 工作的变化。
第11 章总结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 North
Sebastopol， CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
如果你对本书有一些评论或技术上的建议， 请发送电子邮件到bookquestions@oreilly.com。
有关其他图书、讲座、会议、新闻的信息，请访问我们的网站：http://www.oreilly.com。
我们的Facebook：http://facebook.com/oreilly。
我们的Twitter：http://twitter.com/oreillymedia。
我们的YouTube：http://www.youtube.com/oreillymedia。
致谢
本书得以付梓，我们要感谢很多人给予的帮助。感谢在创作早期大纲和草稿以及编辑的过程中，给予过我们帮助和支持的所有人。首先，感谢我们采访和咨询过的所有人，以及参加过研讨会的所有人。我们获得了积极的反馈和的良好建议。其次，还要感谢CA 科技公司的同仁多年来支持我们，并帮助我们举办研讨会和现场的采访。特别感谢阅读我们早期的草稿，并帮助我们完成了本书的所有人。感谢Matt McLarty、James Higginbotham，以及Chris Wood 在百忙之中抽出时间阅读和审查我们的创作，并指出有待提升的地方。后，我们非常感谢O’Reilly Media 的团队。感谢Alicia Young、Justin Billing，以及O’Reilly 全体员工，感谢你们为帮助我们将初的想法变成眼前的这本书所付出的一切努力。

 

 

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式 香港用户　 |　台灣用户　|　大陸用户　|　海外用户
megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.