本周次要修了零碎的一些bug，以及依照教程启了一下后盾环境。
前言
HTTP/1.1有7种申请办法：1、GET；2、POST；3、PUT；4、DELETE；5、HEAD；6、TRACE；7、OPTIONS；
我的项目中罕用的是后面四种。然而本人不太分明申请的过程以及post和put申请之间的区别。于是记录一下。
POST和PUT
对于http的post和put办法，大多数的解释都是，如果是新建一条记录的话就用post，如果是更新一条记录的话就用put。
解释是这样的：
POST办法和PUT办法申请最基本的区别是申请URI（Request-URI）的含意不同。
POST申请里的URI 批示一个能解决申请实体的资源。
PUT办法申请里的URI标识申请里封装的实体--用户代理晓得URI 意指什么，并且服务器不能把此申请利用于其它资源。
比方上面的例子：
我的项目中新建申请例子return this.httpClient.post<User>(`user`, user)更新申请例子return this.httpClient.put<User>(`user/${userId}`, user);能够看到，put申请里的url带着userId，即标示着对应封装的实体。而post申请没有userId，它对应的是解决所有user的一个资源。
另外我尝试的时候，把更新申请的put改post的时候，也就是post办法用来批示实体的时候，能失常应用。如下:
return this.httpClient.post<User>(`user/${userId}`, user);然而我是在angular mockapi下尝试的，没有启动后盾，不分明后台下替换的话有什么区别。
从幂等的性质上看
PUT和POST办法语义中都有批改资源状态的意思，因而都不是平安的。然而PUT办法是幂等的，POST办法不是幂等的，这么设计的理由是：
HTTP协定规定，POST办法批改资源状态时，URL批示的是该资源的父级资源，待批改资源的ID信息在申请体中携带。而PUT办法批改资源状态时，URL间接批示待批改资源。因而，同样是创立资源，反复提交POST申请可能产生两个不同的资源，而反复提交PUT申请只会对其URL中指定的资源起作用，也就是只会创立一个资源。
这么说，方才把put换成post执行更新操作的话，申请可能会产生两个不同的user。
等学习后盾之后再进行试验。
HTTP申请过程
HTTP协定采纳申请/响应模式，客户端向服务器发送一个申请报文，而后服务器响应申请。过程：
1.在浏览器中输出URL，并按下回车键。
2.域名解析
即向DNS服务器申请解析该URL中的域名对应的IP地址。
Domain Name Server，域名服务器，比方拜访JD.com,就会去根服务器去查.com在哪个地位，再查JD在什么地位,最初取得该url的IP地址。
这个DNS服务个别是电信运营商提供的，也能够应用像Google提供的DSN服务器。
3.浏览器依据IP和端口号，和服务器建设TCP连贯
（TCP，Transmission Control Protocol）
拿到域名对应的IP地址之后，浏览器会以一个随机端口（1024<端口<65535）向服务器的web程序（罕用的有httpd，nginx等）80端口发动TCP的连贯申请。先会收回三次握手。
两台计算机之间的通信是靠协定（目前风行TCP/IP协定）来实现的，如果两台计算机应用的通信协议不一样，那是不能进行通信的，所以这个3次握手就相当于试探一下对方是否遵循TCP/IP协定，协定实现后就能够进行通信了，
4.建设TCP连贯后发动http申请
比方浏览器发动了http申请，应用的http的GET办法，申请的URL是/，协定是HTTP/1.0
5.服务器响应申请，返回后果
服务器端web程序接管到http申请当前，就开始解决改申请，解决之后就返回给浏览器html文件。
6.浏览器失去html标签代码
7.浏览器解析html代码中的资源，例如js，css，img等
8.浏览器对页面进行渲染并出现给用户