Web API: The Good Parts
[原书网址](http://www.oreilly.co.jp/books/9784873116860/#toc)
介绍
第一章什么是Web API
1.1API在网络服务中的重要性
基于使用的API1.1.1出现服务
1.1.2移动应用程序和API
1.1.3 API经济
1.2模式不同的API
已公布的1.2.1 API公布的数据和Web服务功能
出版widget的要在其他1.2.2网页贴
1.2.3建设现代Web应用程序
1.2.4开发的智能手机应用程序
1.2.5开发社交游戏
1.2.6合作的内部系统
应公众的1.3做API
无论风险是存在发布1.3.1 API
1.3.2那些暴露的API获得
美丽的设计,1.4的Web API的重要性
1.4.1易于使用的漂亮的网页API设计
1.4.2漂亮的Web API的设计很容易改变
1.4.3网络API漂亮的设计是稳健
1.4.4漂亮的Web API的设计是不以为耻
1.5为了美化网页API是
1.6 REST和Web API
而成为开发商的利益和API设计理念1.7数
1.8结论
的设计和要求的终点的第2章格式
2.1我想设计要暴露的API函数
所需的移动应用程序的API函数2.1.1
2.2 API端点的想法
2.2.1端点的基本设计
2.3 HTTP的方法和终点
2.3.1 GET方法
2.3.2 POST方法
2.3.3 PUT方法
2.3.4 DELETE方法
2.3.5补丁的方法
API的2.4终点设计
在终点的设计考虑访问资源2.4.1
2.4.2小心词使用
不要使用那些需要2.4.3空间和编码字符
使用连字符时2.4.4需要连接的词
2.5搜索和查询设计参数
收购收购位置和数量2.5.1查询参数
2.5.2使用的相对位置的问题
2.5.3我得到的绝对位置数据
2.5.4参数缩小
正确使用2.5.5查询参数和路径
2.6登录和OAuth的2.0
访问令牌过期和更新2.6.1
2.6.2其他类型格兰特
主机名和端点的2.7公共部分
2.8 SSKDs和API设计
2.9 HATEOAS和REST API LEVEL3
2.9.1优势的REST API LEVEL3
2.9.2 REST API LEVEL3
2.10小结
第3章设计响应数据的
3.1数据格式
3.1.1指定数据格式的方法
3.2 JSONP处理
如果你想支持3.2.1 JSONP的礼仪
3.2.2 JSONP和错误处理
中的数据的内部结构的3.3观
3.3.1对响应于用户的内容来选择
3.3.2或信封是必需的
3.3.3是数据应该是平的
3.3.4数组和格式
如何应返回3.3.5数值列的,或是否有继续
各数据的3.4格式
3.4.1各数据的名
3.4.2如何表示数据的性别
格式3.4.3日期
3.4.4大整数和JSON
响应数据的3.5设计
错误的表示3.6
我表示在3.6.1状态代码错误
3.6.2我返回错误信息给客户端
什么应该被包含在3.6.3错误详细信息
我阻止了HTML返回时3.6.4错误
3.6.5维护和状态代码
3.6.6如果你想返回故意不准确的信息
3.7结论
我要充分利用第4章的规格HTTP
使用的HTTP规范4.1的意义
4.2我用正确的状态码
4.2.1200系列:成功
4.2.2300系列中的处理添加是必要
4.2.3如果在客户端的请求的一个问题
4.2.4如果500系列有一个与服务器有问题
4.3高速缓存和HTTP规范
4.3.1过期模型(过期模型)
4.3.2验证模型(模型验证)
4.3.3启发式过期(启发式过期)
4.3.4如果您不希望缓存
4.3.5我指定的缓存单元因人而异
4.3.6 Cache-Control头
4.4指定介质类型
4.4.1指定的内容类型的媒体类型的需要
4.4.2 X-开始的介质类型
4.4.3如果你想自己定义的媒体类型
4.4.4如果要定义使用JSON和XML的新的数据格式
4.4.5介质类型和安全
4.4.6请求数据和媒体类型
4.5同源策略和跨域资源共享
4.5.1 CORS基本交流
4.5.2预检请求
4.5.3 CORS和用户认证信息
4.6我想定义自己的HTTP标头
4.7结论
我做了简单的网络API第5章设计变更
便于设计变更5.1的重要性
5.1.1如果要发布给外部的API
5.1.2在API的情况下,移动应用
5.1.3如果你的API上的Web服务使用
5.2我管理的API版本
我的嵌入版本5.2.1 URI
是什么把5.2.2的版本号
5.2.3我把版本中的查询字符串
5.2.4如何在媒体类型指定版本
5.2.5应采用哪一种方法
准则变更的5.3版本
5.3.1或别名总是返回最新的版本是必需的
5.4我要终止提供的API
5.4.1案例研究:微博的情况下,
5.4.2我应该纳入规范在拨备前结束时间
国家的支持截止到5.4.3使用条款
5.5业务流程层
5.6结论
我做一个6章强大的Web.API
6.1我要保护Web API
6.1.1是否有任何安全问题
6.2在服务器和客户端之间的欺诈手段获得的信息
6.2.1加密的HTTP通信通过HTTPS
6.2.2或100%,如果你使用HTTPS安全
API来访问浏览器6.3中存在的问题
6.3.1 XSS
6.3.2 XSRF
6.3.3 JSON劫持
考虑措施6.4对恶意访问
篡改6.4.1参数
6.4.2重传请求
6.5安全关系的HTTP标头
6.5.1 X-Content-Type的-选项
6.5.2 X-XSS-保护
6.5.3 X帧选项
6.5.4内容安全性策略
6.5.5严格-Transpor T-安全
6.5.6公钥,销
6.5.7 Set-Cookie头和安全
6.6采取措施,大规模接入
6.6.1我想要限制每个用户的访问权限
6.6.2限速装置
6.6.3信件,如果你已经超过了限值
我讲一个6.6.4速率限制用户
6.7结论
您可以在您发布的附录A中的Web API做
附录B网络.API检查表
指数
内容表列
别名为他们的信息
其他的数据格式
应该支持JSONP?
HTTP的时间格式
强大的验证和核查弱
我代表日期的版本号
区分认证机构会发出受到攻击假证书
如果这是不应该的API来从浏览器访问
我看实际API的相应情况
准入限制放宽
限速实施