API:

就是一些预先定义好的函数，目的是能够让应用程序或开发人员能具有访问网络资源的能力，而又无需关心访问的源码，或是裂解内部工作机制的细节。

Restful API规范

1、协议

renst api 与用户的通信协议，总是使用HHTTP协议

2、域名

应该尽量将api部署在专用的域名之下
https://api.example.com

如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。
https://example.com/api/

3、版本

应该将API的版本号放入URL
https://api.example.com/version/

另一种做法是将版本号放在HTTP头信息中但不如放在URL方便和直观

4、路径

路径又称重点，表示API的具体网址。

在RESTful架构中每个网址代表一种资源，所以网址中不能有动词，只能由名词，而且所用的名词往往与数据库的表明对应。一般来说，数据库中的表都是同种记录的“集合”，所以API中的名词也应该是复数。

example：
有一个API提供动物园（zoo）的信息，还包括各种动物和雇员信息，则它的路径应该设计成下面这样。
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
https://api.example.com/v1/employees

5、HTTP动词

post（create） delete（delete） put（update） get（select）

6、过滤信息

如果记录数量很多，APi应该提供参数，过滤返回结果。
?limit=10:指定返回记录的数量
?offset=10:指定返回记录的开始位置
?page=2&per_page=100：指定第几页，以及每页的记录数
?sortby=name&order=asc:指定返回结果按照那个属性排序，以及排序顺序
?animal_type_id=1:指定筛选条件

7、状态码

200
201

204

401

403

404

406

8、错误处理

{
error：“Invalid API key”
}

HTTP协议：

http的重要性：
web service Http+xml
rest大型架构 http+json/xml
各种api
采集、挖矿
Ajax

rest是Http驱动的，别切完全发挥HTTP的能力

HTTP是什么：
一种web常见应用层的网络协议，全程为：超文本传输协议
作为协议：http仅仅是将通信过程规范化，可客户端与服务端能够更好的理解对方想要表达的内容
HTTP是基于TCP传输层实现的，默认的TCP端口号：80

HTTP的特点
1、无状态
2、多次HTTP请求
3、基于TCP协议

HTTP的组成：
HTTP协议分成请求和响应两个部分，请求是指客户端向服务器发送的消息，响应是指服务器收到消息后向客户端返回的消息

URI（统一资源标识符）
http://user:[email protected]:8080/p/a/t/h?query=string#hash

http 协议名称
user 用户名（可选）
pass 对应密码（可选）
host.com 主机域名地址（也可以是IP地址）
8080 端口号 默认 80
/p/a/t/h 资源路径
query=string 参数传递
hash 锚点

HTTP请求与响应
请求：
1、请求行
2、请求头信息
3、请求主体信息
2和3之间要有一个空行

请求格式
请求行 （方法 路径 协议）
请求头信息 （格式为key=value）
空行
请求主体（可选）（发送的内容）

例子：
POST /index.php http/1.1
host： localhost
content-type：application/x-www-form-urlencoded
content-length：25

name=zhangsan

响应行 （协议 状态码 状态文字）
响应头信息（格式为key=value）
空行
主体信息 （发送的内容/none）

RESTful（Representational State Transfer）

百度百科：

RESTFUL是一种网络应用程序的设计风格和开发方式，基于HTTP，可以使用XML格式定义或JSON格式定义。RESTFUL适用于移动互联网厂商作为业务使能接口的场景，实现第三方OTT调用移动网络资源的功能，动作类型为新增、变更、删除所调用资源。

RESTful架构是对MVC架构改进后所形成的一种架构，通过使用事先定义好的接口与不同的服务联系起来。在RESTful架构中，浏览器使用POST，DELETE，PUT和GET四种请求方式分别对指定的URL资源进行增删改查操作。因此，RESTful是通过URI实现对资源的管理及访问，具有扩展性强、结构清晰的特点。

RESTful架构将服务器分成前端服务器和后端服务器两部分，前端服务器为用户提供无模型的视图；后端服务器为前端服务器提供接口。浏览器向前端服务器请求视图，通过视图中包含的AJAX函数发起接口请求获取模型。

项目开发引入RESTful架构，利于团队并行开发。在RESTful架构中，将多数HTTP请求转移到前端服务器上，降低服务器的负荷，使视图获取后端模型失败也能呈现。但RESTful架构却不适用于所有的项目，当项目比较小时无需使用RESTful架构，项目变得更加复杂。

1、资源与URI和URL

a、资源，resources，网络上的具体信息
b、URI：uniform resource identifiter 统一资源标识符，用来唯一的标识一个资源
c、URL：uniform resource locator，统一资源定位器，用来定位某个特定资源

2、表现层，representation

表现层：资源呈现出来的形式
a、纯文本
b、html
c、json

3、状态转移，state transfer

a、HTTP协议是一个无状态的协议
b、GET、POST、PUT、DELETE

REST架构设计6原则

a、Uniform Interface
b、Statelss
c、Cacheble
d、Client-Server
e、Layered System
f、Code on Demand

OAuth2.0的原理介绍-概述

参考：http://www.ruanyifeng.com/blog/2019/04/oauth_design.html

OAuth（开放授权）是一个正式的互联网标准协议

允许第三方网站在用户授权的前提下，访问用户在服务商哪里存储的各种信息。而这种授权无需将用户提供用户名和密码提供给该第三方网站

OAuth允许用户提供一个令牌给第三方网站，一个令牌对应一个特定的第三方网站，同时该令牌只能在特定的事件内访问特定的资源 

A. 客户端从资源拥有者那请求授权。授权请求可以直接发给资源拥有者，或间接的通过授权服务器这种中
介，后者更可取。
B. 客户端收到一个授权许可，代表资源服务器提供的授权。(获取授权码)
C. 客户端使用它自己的私有证书及授权许可到授权服务器验证。
D. 如果验证成功，则下发一个访问令牌。(获取access_token访问令牌)
E. 客户端使用访问令牌向资源服务器请求受保护资源。
F. 资源服务器会验证访问令牌的有效性，如果成功则下发受保护资源。(获取访问的受保护资源)

OAuth几种授权模式

授权码模式----功能最完整、流程最严密的授权模式

简化模式-------不通过第三饭应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了”授权码“这个步骤

密码模式-------需要用户向客户端提供自己的用户名和密码

客户端模式---客户端以自己的名义，而不是以用户的名义，向服务器提供商进行认证

授权码模式：

它的步骤如下：
（A）用户访问客户端，后者将前者导向认证服务器。
（B）用户选择是否给予客户端授权。
（C）假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。
（D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

下面是上面这些步骤所需要的参数。

A步骤中，客户端申请认证的URI，包含以下参数：

response_type：表示授权类型，必选项，此处的值固定为"code"
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，可选项.认证服务器会原封不动地返回这个值。(如果是你自己实现的oauth2.0服务端，可以不校验这个参数，client端就可以不管这个参数)

C步骤中，服务器回应客户端的URI，包含以下参数：

code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。
code：表示上一步获得的授权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示客户端ID，必选项。
client_secret:客户端**

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

token的设计及加密方法

无需核对用户名密码的Token验证机制------无法被伪造的Token

hmac(哈希运算消息认证码)简介

Token的基本设计原则：

Token不携带用户敏感信息

无需查询数据库，Token可以进行自我验证

hamac简介：
作用：

验证消息是否被篡改 公式：

HMAC(K,M) = H (K⊕opad | H (K⊕ipad | M)) 使用python的hmac模块直接计算 hmac.new("secret123456",value).digest()

缺陷： 无法抵御重放攻击

验证Token的有效性：

验证验证码是否一致

验证码是否过期

验证这个Token是否属于被请求数据的用户