现代API:通往架构师之门
1 概述
1.1 什么是架构和架构师
1.2 这本书是为谁写的
1.3 为什么写作此书
1.4 通往架构师之路的路线图
1.5 架构师应该具备的素质
1.6 对架构师的学习和培养过程的几点建议
1.7 本书的主要内容
1.8 总结
第1部分 基础篇
2 重新看待系统集成
2.1 系统集成历史的快速回放
2.2 到底什么是系统集成
2.2.1 系统集成之信息更新
2.2.2 系统集成之信息组合
2.2.3 系统集成之连锁行动
2.3 系统集成的技术组成部分
2.3.1 BUS——高速公路
2.3.2 连接器——高速公路的进出口
2.3.3 CDM——高速公路运输的集装箱
2.3.4 数据转换——运输过程中的货物处理
2.4 系统集成应用的考虑
2.4.1 系统集成的过程中到底要完成什么任务
2.4.2 如何保证系统集成过程中数据传递的可靠性
2.4.3 如何使用消息服务器
2.5 实战：PLM数据与现有系统的集成
2.5.1 项目背景
2.5.2 业务痛点
2.5.3 技术难点
2.5.4 解决方案及经验教训
2.6 总结
3 系统之间相互作用的模式
3.1 系统集成模式简介
3.2 系统集成模式中几个最重要的概念
3.2.1 主题与队列在消息传递中的区别
3.2.2 消息服务器所使用的储存－转送
3.2.3 消息服务器的容错和高可用性
3.2.4 分级式事件驱动架构及其实际应用
3.3 系统集成模式的实战应用和分析
3.3.1 消息的顺序处理
3.3.2 持久订阅如何实现
3.3.3 命令类消息的应用
3.3.4 事件消息的使用
3.3.5 回复地址的使用
3.3.6 消息传递搭桥的使用
3.3.7 消息信封的使用
3.4 总结
4 常见的参与集成的功能系统
4.1 功能系统与集成基础设施的连接
4.2 常见功能系统的功能和类型
4.3 总结
5 究竟什么是服务
5.1 什么是服务
5.2 是谁在推动服务的重复使用
5.3 服务的操作
5.4 服务的界面
5.5 服务操作的粒度
5.6 服务的组合——SOA
5.7 实战：数据
5.7.1 项目背景
5.7.2 业务痛点
5.7.3 技术难点
5.7.4 解决方案及经验教训
5.8 总结
6 系统集成项目的实施步骤
6.1 系统集成与服务项目概述
6.2 系统集成与服务项目的具体实施步骤
6.3 设计和开发阶段
6.3.1 搜集项目业务功能要求
6.3.2 架构设计
6.3.3 细节设计
6.3.4 代码编写和单元测试
6.3.5 集成测试
6.4 测试和验收阶段
6.4.1 质量保证（QA）部署
6.4.2 质量保证（QA）测试
6.4.3 用户验收（UA）部署
6.4.4 用户验收测试（UAT）
6.4.5（可选项）操作验收测试（OAT）
6.5 运维、培训和交付阶段
6.5.1 生产环境部署
6.5.2 试运行
6.5.3 培训及文档提交
6.5.4 项目验收
6.6 总结
7 集成项目与公共服务
7.1 公共服务的具体内容
7.1.1 日志服务
7.1.2 出错处理服务
7.1.3 ID映射服务
7.1.4 顺序处理服务
7.1.5 系统及应用监控服务
7.1.6 应用、服务、API的分析服务
7.2 业务项目的项目模板及其与公共服务的互动
7.3 总结
8 SOA在实施中的局限性
8.1 SOA在具体实施中的做法
8.1.1 SOA的设计原则
8.1.2 SOA绩优中心
8.2 深挖SOA的初衷
8.3 SOA的适用范围和局限性
8.4 总结
第2部分 正篇——现代API、应用互联网
9 现代API的引入、应用互联网
9.1 什么是（现代）API
9.1.1 REST架构的特点
9.1.2 REST架构的特点在API中的具体应用
9.2（现代）API流行背后的原因
9.2.1 API和云平台的普及
9.2.2 API与企业数字化转型、应用互联网以及API经济
9.3 API的平台和工具有待进一步地统一和标准化
9.4 一个RESTAPI的结构
9.5 对API的认识不是一蹴而就的
9.6 动手开发API——先尝为快
9.7 总结
10 围绕API的开发工作
10.1 API的生命周期
10.1.1 API的设计生命周期
####### 10.1.1.1 API的设计
####### 10.1.1.2 API的建模
####### 10.1.1.3 API的模拟服务
####### 10.1.1.4 API模型的用户验证和反馈
10.1.2 API的运维生命周期
####### 10.1.2.1 API的代码开发
####### 10.1.2.2 API的代码测试
####### 10.1.2.3 API的部署
####### 10.1.2.4 API的管理
####### 10.1.2.5 API的发布
####### 10.1.2.6 API的运行和维护
10.2 API的调用者
10.3 API项目中的人员和流程
10.3.1 什么是使能中心
10.3.2 围绕使能中心的不同角色
10.3.3 使能中心与绩优中心的区别
10.3.4 建立使能中心的具体步骤
####### 10.3.4.1 评估企业现有的集成能力
####### 10.3.4.2 建立使能中心的运行模式
####### 10.3.4.3 开发并发布作为基础资源的API
####### 10.3.4.4 在企业内推广使能中心的运行模式
####### 10.3.4.5 推动企业内采用已有API资源的广度和深度
####### 10.3.4.6 监测企业使能中心运行的关键指标
10.3.5 建立使能中心的好处
10.4 总结
11 API与微服务
11.1 什么是微服务
11.2 微服务与服务的关系
11.3 微服务与API的关系
11.4 总结
12 API与云计算
12.1 云计算需求的由来
12.2 云计算对API技术的影响
12.2.1 云计算的平台能为你的API和应用提供多少服务
12.2.2 现有系统之间的连接是否受到影响
12.2.3 是否需要增加安全措施
12.2.4 如何将API负责对内和对外的部分分开
12.3 实战：全云和云－本地混合型的API平台
12.3.1 项目1背景
12.3.2 项目1云平台的架构
12.3.3 项目2背景
12.3.4 项目2混合型平台的架构
12.4 总结
13 最佳实践的经验
13.1 关于系统集成的最佳实践
13.1.1 不要以“数据复制”的思考方式设计系统集成
13.1.2 尽量避免使用批处理文件的方式
13.1.3 对消息服务器运行的认识
13.1.4 使用SEDA的架构模式来提高系统集成整体设计的可靠性
13.1.5 对容错、负载平衡和高可用性的考虑
13.1.6 对灾难恢复设置的考虑
13.1.7 接收JMS消息时的消息确认方式对消息处理可靠性的影响
13.2 关于API的最佳实践
13.2.1 在设计API的过程中使用“资源”的字眼，而不要使用“数据”
13.2.2 不要使用API的概念和方式来做系统集成
13.2.3 API还是连接器
13.2.4 API实施中的出错处理
13.2.5 API的URI的每一个部分都应该是名词，而不是动词
13.2.6 API的版本管理
13.3 关于架构设计的最佳实践
13.3.1 不要使用UML的时序图来编写系统集成的用例文件
13.3.2 注意区分设计中功能方面和非功能方面的要求
13.3.3 不要在没有系统性能指标要求的情况下对系统进行性能的评价和测试
13.3.4 数据验证逻辑与数据的关系
13.3.5 API、服务和集成中均不保留状态
13.4 总结
14 围绕API的展望
14.1 关于企业的IT欠债
14.2 利用API产生新的业务——创新和数字化转型
14.2.1 优步（Uber）的创新
14.2.2 邮局的数字化转型
14.2.3 电力公司旨在提高零售用电顾客满意度的数字化转型
14.2.4 玩具公司旨在减少货运差错和加快货款回收的数字化转型
14.3 利用API产生应用互联网和API经济
14.4 总结
第3部分 闲篇——感悟与随想
15 架构师的人文情怀
15.1 关于学习过程中的三个境界
15.2 架构师所要具备的硬实力
15.3 架构师所要具备的软实力
15.3.1 时刻分清目的和手段
15.3.2 处处讲究形式逻辑
15.3.3 强调利用抽象思维的能力
15.3.4 表达和交流要看对象
15.3.5 坚持原则，但也要知道妥协
15.3.6 知之为知之，不知为不知
15.4 架构师所处的大环境
15.4.1 架构师的职业规划
15.4.2 软件工程问题与业务问题的分离
15.4.3 高校计算机软件课程设置与现实对架构师要求的匹配问题
15.5 总结
附录A 关于实践
附录B 集成中常遇到的功能系统
思维导图
防止博客图床图片失效，防止图片源站外链：
http://www.processon.com/chart_image/5e5b9b75e4b02bc3ad6ac51d.png)
思维导图在线编辑链接：