From 1ee2e880e1d876d2061b3f5648608f46ec9da955 Mon Sep 17 00:00:00 2001 From: Omooo <869759698@qq.com> Date: Mon, 3 Jun 2019 20:59:27 +0800 Subject: [PATCH] =?UTF-8?q?add=20Get=20=E5=92=8C=20Post=20=E7=9A=84?= =?UTF-8?q?=E5=8C=BA=E5=88=AB?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- blogs/Interview/Get 和 Post 的区别.md | 119 ++++++++++++++++++ blogs/Interview/面试题集.md | 12 ++ .../computer_systems/计算机系统漫游.md | 9 ++ 3 files changed, 140 insertions(+) create mode 100644 blogs/Interview/Get 和 Post 的区别.md create mode 100644 blogs/Interview/面试题集.md create mode 100644 blogs/computer_network/computer_systems/计算机系统漫游.md diff --git a/blogs/Interview/Get 和 Post 的区别.md b/blogs/Interview/Get 和 Post 的区别.md new file mode 100644 index 0000000..c590c93 --- /dev/null +++ b/blogs/Interview/Get 和 Post 的区别.md @@ -0,0 +1,119 @@ +--- +Get 和 Post 请求的区别? +--- + +#### 官方文档 + +GET RFC 文档:[https://tools.ietf.org/html/rfc2616#section-9.3](https://tools.ietf.org/html/rfc2616#section-9.3) + +POST RFC 文档:[https://tools.ietf.org/html/rfc2616#section-9.5](https://tools.ietf.org/html/rfc2616#section-9.5) + +#### 典型回答 + +GET 和 POST 本质上没有任何区别,之所以区分开来,是为了让请求更加有语义而已。 + +GET 的语义是请求获取指定的资源,GET 方法是安全、幂等、可缓存的,GET 方法的报文主体没有任何语义。 + +POST 的语义是对指定的资源进行处理,POST 方法是不安全、不幂等、(大部分实现)不可缓存的。 + +#### 知识扩展 + +##### 三个特性 + +在 RFC 中定义了 HTTP 方法的几个性质: + +1. Safe 安全性 + + 这里的「安全」和通常理解的「安全」意义不同。如果一个方法的语义本质上是「只读」的,那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法,就不应该引起服务端任何的状态变化,因此也是无害的。RFC 定义,GET、HEAD、OPTIONS 和 TRACE 这几个方法是安全的。 + + 这个定义只是规范,并不能保证方法的实现就是安全的。比如你完全可以用 GET 方法去修改信息 + + 引入安全的概念目的是为了方便网络爬虫和缓存,以免调用或者缓存某些不安全方法时引起某些意外的后果。User Agent(浏览器)应该在执行安全和不安全方法时作出区别对待,并给予用户以提示。 + +2. Idempotent 幂等性 + + 幂等性是指同一个请求方法执行多次和仅执行一次的效果是相同的。按照 RFC 规范,PUT、DELETE 和安全方法都是幂等的。同样,这也仅仅是规范,服务端实现是否幂等是无法确保的。引入幂等主要是为了处理同一个请求重复发送的情况,比如在请求响应前失去连接,如果方法是幂等的,就可以放心的重新发送请求。这也是浏览器在后退/刷新时遇到 POST 会提示用户,因为 POST 语义不是幂等的,重复请求会带来意想不到的后果。 + +3. Cacheable 可缓存性 + + 顾名思义就是一个方法是否可以被缓存,在 RFC 中,GET、HEAD 和某些情况下的 POST 都是可被缓存的,但是大多数浏览器的实现里仅仅支持 GET 和 HEAD。 + +在这三个特性里一直都在强调,这只是一种规范,协议不等于实现。 + +##### 长度限制? + +网络上大多都会说 GET 的 URL 会有长度上的限制,而 POST 将数据放入 BODY 中,数据可以非常大。实际上,HTTP 协议里面并没有规定 URL 和 BODY 的长度限制,对 URL 的限制大多数是浏览器和服务器的原因。浏览器的原因就不说了,服务器是因为处理长 URL 要消耗比较多的资源,为了性能和安全(防止恶意构造长 URL 来攻击)考虑,会给 URL 长度加限制。 + +##### POST 方法比 GET 方法安全? + +有人说 POST 比 GET 安全,因为数据在地址栏不可见。这是一种比较小儿科的说法,从传输的角度来说,它们都是不安全的,因为 HTTP 在网络上是明文传输,完全可以在网络节点上抓包就能获取完整数据报文。想要安全传输,就只有加密了,也就是 HTTPS。 + +##### POST 产生两个 TCP 数据包? + +有些文章中提出,POST 会将 HEADER 和 BODY 分开发送,先发送 HEADER,待服务端返回 100 状态码之后再发送 BODY。这也是不严谨的,首先就是在 RFC 中并没有这样的说法,其次,一些浏览器的实现不同,也会导致实际上测试根本不会有这种情况。 + +##### 八种请求方法 + +HTTP 请求最初设定了八种方法,这八种方法本质上没有任何区别,只是让请求更加语义化: + +1. OPTIONS + + 返回服务器所支持的请求方法,一般用于调试,多数线上服务都不支持。 + +2. GET + + 向服务器获取指定资源。 + +3. HEAD + + 和 GET 一致,只不过响应体不返回,只返回响应头。 + +4. POST + + 向服务器提交数据,数据放在请求体里。 + +5. PUT + + 和 POST 相似,只是具有幂等性,一般用于更新。 + +6. DELETE + + 删除服务器上的指定资源。 + +7. TRACE + + 回显服务端收到的请求,一般用于调试。 + +8. CONNECT + + 现在多用于 HTTPS 和 WebSocket。 + +##### RESTful API + +服务端根据不同的请求方式,可以做不同的处理,同时,根据不同的请求,还可以设计出不同风格的应用程序接口。这就引出了 Representational State Tansfer,英文缩写就是 REST,中文意思即表述性状态转移,可以理解为客户端和服务端的交互形式。而符合这种交互形式的接口设计,就被叫做 RESTful API,这种风格有以下特点: + +1. 使用名词而不是使用动词 + + 例如 /getStudent 或 /searchStudents 应该改为 /students + +2. GET 用于查询,PUT、POST、DELETE 用于修改 + +3. 使用名词复数而不使用单数 + +4. 在 HTTP 请求的 HEADER 里定义序列化类型 + + 例如:Content-Type:application/json + +5. 请求的集合应设定好过滤条件、排序、字段、分页等 + + 例如:/students?page=1&size=10 + +6. 接口要版本化 + + 例如:api/v1/students + +7. 要有 HTTP 状态码 + +#### 参考 + +[get 和 post 的区别?](https://www.zhihu.com/question/28586791/answer/145424285) \ No newline at end of file diff --git a/blogs/Interview/面试题集.md b/blogs/Interview/面试题集.md new file mode 100644 index 0000000..3c5ce27 --- /dev/null +++ b/blogs/Interview/面试题集.md @@ -0,0 +1,12 @@ +--- +面试题集 +--- + +#### 前言 + + + +#### 目录 + +[Get 和 Post 请求的区别?] + diff --git a/blogs/computer_network/computer_systems/计算机系统漫游.md b/blogs/computer_network/computer_systems/计算机系统漫游.md new file mode 100644 index 0000000..e88cf72 --- /dev/null +++ b/blogs/computer_network/computer_systems/计算机系统漫游.md @@ -0,0 +1,9 @@ +--- +计算机系统漫游 +--- + +#### 目录 + +1. 思维导图 +2. +