WebAPI的设计与开发

1.Web API设计、开发与运维zui佳实践！
2.实例丰富，分析了美国各大知名网站的API设计细节。
3.内容详实，易于理解，Web API新手bi备！

API如果设计得不好，不仅会很难用，而且公开之后的运维也很困难，因此设计优美的API非常重要。本书认为“设计优美的API易于使用、便于更改、健壮性好、不怕公之于众”，并基于这一观点详细阐述了如何有效地设计、开发和运维API、如何避免容易掉入的陷阱等。目标是设计出访问URI后返回XML或JSON等数据的简洁的API，即XML over HTTP方式或JSON over HTTP方式的API。

本书结合丰富的实例，详细讲解了Web API的设计、开发与运维相关的知识。第1章介绍Web API的概要；第2章详述端点的设计与请求的形式；第3章介绍响应数据的设计；第4章介绍如何充分利用HTTP协议规范；第5章介绍如何开发方便更改设计的Web API；第6章介绍如何开发牢固的Web API。

水野贵明（作者）
1973年出生于东京。自由软件开发者兼技术书作译者。是JavaScript：The Good Parts、Third-Party JavaScript、 High Performance JavaScript、The Principles of Object-Oriented JavaScript等图书的日文版译者，著有《Web应用程序测试方法》（合著）。

盛荣（译者）
曾就职于爱立信、Autodesk等公司，长期从事软件、互联网技术相关领域的研发、测试等工作。热爱技术，对IT相关的新闻、历史等有浓厚兴趣。

目　录

译者序　xi

前言　xv

第1章　什么是Web API　1
1．1　Web API的重要性　3
1．1．1　通过API才能使用的在线服务出现　5
1．1．2　移动应用与API　7
1．1．3　API的经济学　7
1．2　各种各样的API模式　8
1．2．1　将已发布的Web在线服务的数据或功能通过API公开　8
1．2．2　将附加在其他网页上的微件公开　9
1．2．3　构建现代Web应用　10
1．2．4　开发智能手机应用　11
1．2．5　开发社交游戏　11
1．2．6　公司内部多个系统的集成　12
1．3　应该通过API公开什么　12
1．3．1　公开API是否会带来风险　13
1．3．2　公开API能得到什么　14
1．4　设计优美的Web API的重要性　15
1．4．1　设计优美的Web API易于使用　15
1．4．2　设计优美的Web API便于更改　16
1．4．3　设计优美的Web API健壮性好　16
1．4．4　设计优美的Web API不怕公之于众　16
1．5　如何美化Web API　17
1．6　REST与Web API　18
1．7　作为目标对象的开发人员数量与API的设计思想　19
1．8　小结　20

第2章　端点的设计与请求的形式　21
2．1　设计通过API公开的功能　21
2．2　API端点的设计思想　24
2．3　HTTP方法和端点　31
2．3．1　GET方法　32
2．3．2　POST方法　33
2．3．3　PUT方法　33
2．3．4　DELETE方法　34
2．3．5　PATCH方法　35
2．4　API端点的设计　37
2．4．1　访问资源的端点设计的注意事项　41
2．4．2　注意所用的单词　43
2．4．3　不使用空格及需要编码的字符　43
2．4．4　使用连接符来连接多个单词　44
2．5　搜索与查询参数的设计　45
2．5．1　获取数据量和获取位置的查询参数　46
2．5．2　使用相对位置存在的问题　47
2．5．3　使用绝对位置来获取数据　48
2．5．4　用于过滤的参数　49
2．5．5　查询参数和路径的使用区别　52
2．6　登录与OAuth 2．0　53
2．6．1　access token的有效期和更新　58
2．6．2　其他Grant Type　59
2．7　主机名和端点的共有部分　61
2．8　SSKDs与API的设计　63
2．9　HATEOAS和REST LEVEL3 API　64
2．9．1　REST LEVEL3 API的优点　67
2．9．2　REST LEVEL3 API　67
2．10　小结　68

第3章　响应数据的设计　69
3．1　数据格式　69
3．2　使用JSONP　74
3．2．1　支持JSONP的操作方法　75
3．2．2　JSONP与错误处理　77
3．3　数据内部结构的思考方法　79
3．3．1　让用户来选择响应的内容　81
3．3．2　封装是否必要　82
3．3．3　数据是否应该扁平化　83
3．3．4　序列与格式　85
3．3．5　该如何返回序列的个数以及是否还有后续数据　88
3．4　各个数据的格式　90
3．4．1　各个数据的名称　90
3．4．2　如何描述性别数据　92
3．4．3　日期的格式　95
3．4．4　大整数与JSON　96
3．5　响应数据的设计　97
3．6　出错信息的表示　98
3．6．1　通过状态码来表示出错信息　98
3．6．2　向客户端返回详细的出错信息　99
3．6．3　如何填写详细的出错信息　101
3．6．4　发生错误时防止返回HTML　102
3．6．5　维护与状态码　102
3．6．6　需要返回意义不明确的信息时　103
3．7　小结　104

第4章　最大程度地利用HTTP协议规范　105
4．1　使用HTTP协议规范的意义　105
4．2　正确使用状态码　107
4．2．1　2字头状态码：成功　109
4．2．2　3字头状态码：添加必要的处理　111
4．2．3　当客户端请求发生问题时　113
4．2．4　5字头状态码：当服务器端发生问题时　115
4．3　缓存与HTTP协议规范　116
4．3．1　过期模型　117
4．3．2　验证模型　120
4．3．3　启发式过期　122
4．3．4　不希望实施缓存的情况　123
4．3．5　使用Vary来指定缓存单位　123
4．3．6　Cache-Control首部　125
4．4　媒体类型的指定　127
4．4．1　使用Content-Type指定媒体类型的必要性　129
4．4．2　以x-开头的媒体类型　130
4．4．3　自己定义媒体类型的情况　131
4．4．4　使用JSON或XML来定义新的数据格式的情况　132
4．4．5　媒体类型与安全性　133
4．4．6　请求数据与媒体类型　134
4．5　同源策略和跨域资源共享　136
4．5．1　CORS基本的交互　137
4．5．2　事先请求　138
4．5．3　CORS与用户认证信息　139
4．6　定义私有的HTTP首部　139
4．7　小结　141


第5章　开发方便更改设计的Web API　143
5．1　方便更改设计的重要性　143
5．1．1　公开发布的API　144
5．1．2　面向移动应用的API　145
5．1．3　Web服务中使用的API　145
5．2　通过版本信息来管理API　146
5．2．1　在URI中嵌入版本编号　147
5．2．2　如何添加版本编号　149
5．2．3　在查询字符串里加入版本信息　151
5．2．4　通过媒体类型来指定版本信息　152
5．2．5　应该采用什么方法　153
5．3　版本变更的方针　153
5．4　终止提供API　155
5．4．1　案例学习：Twitter废除旧版本的API　156
5．4．2　预先准备好停止服务时的规范　156
5．4．3　在使用条款中写明支持期限　159
5．5　编排层　160
5．6　小结　162

第6章　开发牢固的Web API　163
6．1　让Web API变得安全　163
6．2　非法获取服务器端和客户端之间的信息　165
6．2．1　用HTTPS对HTTP通信实施加密　165
6．2．2　使用HTTPS是否意味着100%安全　167
6．3　使用浏览器访问API时的问题　169
6．3．1　XSS　169
6．3．2　XSRF　174
6．3．3　JSON劫持　176
6．4　思考防范恶意访问的对策　180
6．4．1　篡改参数　181
6．4．2　请求再次发送　183
6．5　同安全相关的HTTP首部　185
6．5．1　X-Content-Type-Options　185
6．5．2　X-XSS-Protection　186
6．5．3　X-Frame-Options　186
6．5．4　Content-Security-Policy　187
6．5．5　Strict-Transport-Security　187
6．5．6　Public-Key-Pins　188
6．5．7　Set-Cookie首部和安全性　189
6．6　应对大规模访问的对策　191
6．6．1　限制每个用户的访问　192
6．6．2　限速的单位　194
6．6．3　应对超出上限值的情况　195
6．6．4　向用户告知访问限速的信息　198
6．7　小结　204

附录A　公开Web API的准备工作　205
A．1　提供API文档　205
A．2　提供沙盒API　206
A．3　API Console　207
A．4　提供SDK　209

附录B　Web API确认清单　211

　　《Web API的设计与开发》：
　　例如，假设有一个在线服务同时提供了面向智能手机客户端的API和面向PC的Web站点。用户通过注册、登录来使用该服务。该服务使用cookie来管理Web站点的会话信息。如果该服务在面向智能手机客户端的API里也同样使用cookie来进行会话信息的交互（在智能手机客户端程序里生成Cookie首部并发送），导致会话信息被浏览器共享的话，那结果会如何呢？
　　在这种情况下，即使我们没有预设会通过浏览器来访问API，实际上仅仅通过浏览器发送cookie信息这一操作，也能完成API的认证。当攻击者在SCRIPT元素里附加URI时，就有可能通过恶意网站来窃取或篡改机密信息等。
　　因此，当无需通过浏览器来访问API时，就要使用不同的会话管理方式，或者使用私有HTTP首部来识别客户端，或者使用下一节介绍的校验和的方式等，来防范使用SCRIPT元素从浏览器访问API导致的安全问题。
　　……