关于前端:http请求

本周次要修了零碎的一些 bug，以及依照教程启了一下后盾环境。

HTTP/1.1 有 7 种申请办法：1、GET；2、POST；3、PUT；4、DELETE；5、HEAD；6、TRACE；7、OPTIONS；
我的项目中罕用的是后面四种。然而本人不太分明申请的过程以及 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 协定采纳申请 / 响应模式，客户端向服务器发送一个申请报文，而后服务器响应申请。过程：

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. 浏览器对页面进行渲染并出现给用户

关于前端:http请求

前言

POST 和 PUT

从幂等的性质上看

HTTP 申请过程