http请求
http请求是什么
http请求是超文本传输协议，既请求和响应的协议，一般运行在TCP协议上（还有个UDP）由协议域名端口所组成，作用于让客户端与服务端之间有联系，默认端口80（https443）。
http请求行（链接）的组成
协议：http或者https
域名：由.串联，可有多级域名，顶级域名常见com，org（国际通用顶级域名），cn（我国管理的顶级域名），net
端口：数字组成，但6xxx的不能使用：原因是这些端口是一些缺省端口，有安全风险，易中毒，被常用浏览器所屏蔽。
http请求报文的构成
- 请求行：协议，url，请求方式三部分组成 eg. GET /api/basiclist HTTP/1.1
- 请求头 对客户端信息的描述，也可以填充一些基本信息与自定义头中
- 空行 ： 请求头字段的最后一行，用于隔断请求头和请求体
- 请求体 ： 携带的body数据
http响应报文的构成
- 响应行：协议版本，状态码，状态码构成 eg. HTTP/2 200 ok
- 响应头：一组键值对，对接口响应的叙述
- 空行：隔断响应头和响应体
- 响应体：返回的资源
常见的http请求方式
- get 获取资源
- post。添加资源或表单提交
- put。修改资源
- delete 删除资源
- options。预检请求，询问连接是否通畅，是否有缓存数据直接获取，询问方法是否可以被执行，常见于https
- lock 加锁
- unlock。解锁
- patch。 部分资源更新
- copy。复制
- move。移动
常见的请求头
- Accept: 浏览器可接收数据的格式
- User-Agent：客户端名称
- Host：对应网址的名称和端口号
- connection： 服务器是否可以被长久性维持固定的http连接，http/1.1的用keep-alive做为默认值，以保证浏览器连接是不需要每次都建立关联
- cookie 通过接口请求设置credentials凭证来携带cookie信息
- referer：产生请求的网页url，用于追踪请求发起的网站。
- content-type客户端请求的内容类型
- accept-charset浏览器可被接收的字符编码
- accept-encoding浏览器可接受
常见响应头
- Allow：服务器支持的请求方式
- Location：当接口重定向时要跳转的资源地址
- Content-Type:数据响应格式
- Date:当前时间
- Expires：强缓存直接读取本地数据的文档过期时间，适用Http1和2
- Cache-Control: 是否使用强缓存并设置对应时间适用Http2，常用max-age=n s计算
- ETag: 协商缓存，会访问后端询问数据是否改变未改变用缓存数据（304），hash值 适用Http2
- Last-Modied: 协商缓存，返回时间戳，适用Http1
- Refresh 浏览器要在多久后进行文档刷新
TCP和UDP的区别
TCP协议
接口请求的协议，他可以提供在对应IP下更可靠的数据传输，面向连接，端对端的传输，传输可靠，但是速度慢，建立连接的开销大
常用的端口有：
- FTP文件传输协议，21端口，一般用来文件传输
- Telnet远程登录端口，主要是身份远程连接，做通信使用
- SMTP邮件传输协议，25端口，主要做邮件传输，常见的免费邮件服务eg.QQ邮箱，主要是作用消息发送至邮箱使用
- POP3 用于接收邮件，对比SMTP更为常用，110端口，更便捷，可以直接用邮件程序收到邮件
- HTTP协议，虽然他注重速度，可以走UDP协议，但是处于安全以及传输数据量大小的考虑，还是使用TCP更为可靠，更为标准，常用80端口
- WebSocket协议，独立的，通过在http1.1协议上进行握手的双向通信协议，通过第一次的http协议的101状态码握手成功后就直接通过TCP联系，关键消息头Upgrade：websocket，来切换请求方式
UDP协议
接口请求协议，面向非连接的，传输数据少，速度快的一个协议，数据传输安全性小
常用端口：
- DNS域名解析服务，常用53端口，用于创建客户端与服务端之间的联系
- SNMP网络管理协议，161端口，主要是管理网络设备的
- OICQ程序接受服务，无连接协议，多用于多人聊天，虽然我也没看太懂。
区别
- TCP协议面线连接，数据传输安全可靠，可传输大数据，可接收多个请求一次性接收，无边界，保证对方可以收到给出响应，但是首部消耗20字节
- UDP协议面向无连接，数据发出后就代表成功，安全性小，可能会丢失，有边界，发送多少次服务器就接收多少次，首部消耗8字节
Restful风格介绍
是什么（表现层状态转化）
restful风格是更加语义化，更加有针对性的一种接口请求风格，通过对同一uri的不同请求方式做针对性的数据处理，是现在最常用的一个风格理念，具有安全性和幂等性，设置api更面向资源化符合CRUD，是基于Rest架构分布式系统思想的API设计风格。
rest原则：
- 单个uri对应一个资源，通过rest操作对其进行crud的操作
- 表现层通过accpet获取浏览器接收信息的格式和content-type看请求要求返回数据的格式将获取的资源做具体展示
- 通过下述常用规则做状态转化
为什么使用
- 现服务端多以rest架构进行接口开发用于web应用，而restful风格是符合rest开发API的
- 符合单一uri对应一个资源的理念，使操作和问题查询更加清晰明了
- 通过单一uri的不同请求方式做不同的操作
- 扩展？： 超媒体驱动应用状态HATEOAS理念，响应结果中同时反馈当前接口内容的相应接口，其中links就是反馈的针对该资源可执行的其他类型操作
{
"bookId": 918,
"bookName": "关于谁的接口",
"author": "谁写的",
"links": [
{
"rel": "self",//类型之当前接口，还有以下其他值edit、search、related、first、last、previous、next类型
"type": "get",//请求方式
"href": "http://xxx.com/user/info"//请求接口
},
{
"rel": "collection",
"type": "post",
"href": "http://xxx.com/user/add"
}
]
}
- 便于前后端分离，前端关注调用，后端关注被调用
- restful风格可以被拆分为 资源、表象层、状态转化，通过对单一资源的指定，按照表现层（请求头的content-type指定的现实形态），将数据库的内容转化出来
- 可以由SOAP的简单对象访问协议转换为SOA的面向服务的架构
常用规则（http method）
- get获取数据
- post新增数据
- put或patch更改数据（put是更改完整资源，patch是更改资源属性）
- delete删除数据
注意事项
- 获取资源时uri名称定义用复数，如list，blogs等
- 书写携带版本信息，不发布无版本的api
- 需使用http或https协议进行
- 与hybrid风格（这里是风格不是架构，类似于RPC风格）不同，hybrid风格的最主流的用法是，使用get方法获取资源，用post方法实现资源的创建、修改和删除，而rest架构尊崇的redtful风格是什么方法干什么样的事
- http协议无状态传输，用户身份信息认证等隐私公用校验信息一般放在head中，在后端的中间件里做身份校验判别
- 数量过多时为了服务端精准匹配所需要的信息需在API中携带过滤信息，如limit要几条，offset从第几条要等
- restful只是一种风格，不会强制必须按照这个风格的要求完成编码，在使用该风格时要注意这些
- 有一定的缺点： 只可进行简单的CRUD，复杂的文件传输，批量下载等不适很适用；错误码所代表的含义范围大，仅凭单一code的含义无法定位具体问题
对于返回的操作
- 依赖http状态码，做接口不同状态的处理-对应文章Http 响应码
依赖code的不同，做针对性处理，如200成功，204资源不存在，401请注册403无权限500服务端异常502代理或网关出错无响应...
若发生错误，因为code代表的范围大，一般会携带message信息，做同一code的不同错误处理，如资源异常，服务端出错，资源不存在还是接口不存在...
