GET与POST

浏览器的GET和POST

这里特指浏览器中非Ajax的HTTP请求，即从HTML和浏览器诞生就一直使用的HTTP协议中的GET/POST。浏览器用GET请求来获取一个html页面/图片/css/js等资源；用POST来提交一个

表单，并得到一个结果的网页。

GET

‘读取’一个资源，反复读取不应该对被访问的数据

有副作用，无副作用也称为"幂等"（Idempotent)

因为GET因为是读取，对GET请求的数据就可以缓存。这个缓存可以做到浏览器本身上（彻底避免浏览器发请求）

 

请求发送方式

*浏览器直接发出的GET只能由一个url触发

*所以想要传参，只能依靠url上附带queryString。

但是HTTP协议本身并没有这个限制，这是浏览器的限制。

一般会泛泛的说“GET请求没有body，只有url，请求数据放在url的querystring中；POST请求的数据在body中“。但这种情况仅限于浏览器发请求的场景。

 

POST

在页面里 标签会定义一个表单。点击其中的submit元素会发出一个POST请求让服务器做一件事。这件事往往是有副作用的，不幂等的。

不幂等也就意味着不能随意多次执行。因此也就不能缓存。

 

请求发送方式

*浏览器的POST请求都来自表单提交

*表单的数据被浏览器用编码到HTTP请求的body里。

浏览器在POST一个表单时，url上也可以带参数，只要里的url带queryString就行。只不过表单里面的那些用 等标签经过用户操作产生的数据都在会在body里。

发出的POST请求的body主要有有两种格式

application/x-www-form-urlencoded 传输简单的数据，

大概就是"key1=value1&key2=value2"这样的格式。

multipart/form-data 传文件，

采用后者是因为application/x-www-form-urlencoded的编码方式对于文件这种二进制的数据非常低效。

 

接口中的GET和POST

这里是指通过浏览器的Ajax api,postman之类的工具发出来的GET和POST请求

 

自由性

当用HTTP实现接口发送请求时，就没有浏览器中那么多限制了，只要是符合HTTP格式的就可以发,

所以可以非常自由的去利用格式，例如可以自己开发接口让POST一半的参数放在url的querystring里，另外一半放body里；你甚至还可以让所有的参数都放Header里——可以做各种各样的定制，只要请求的客户端和服务器端能够约定好。

 

REST

一些列接口规范/风格中名气最大的当属REST，REST充分运用GET、POST、PUT和DELETE，约定了这4个接口分别获取、创建、替换和删除“资源”，

json格式

REST最佳实践还推荐在请求体使用json格式，

json相对于x-www-form-urlencoded的优势在于

(1）可以有嵌套结构；

(2）可以支持更丰富的数据类型。

通过一些框架，json可以直接被服务器代码映射为业务实体。用起来十分方便。但是如果是写一个接口支持上传文件，那么还是multipart/form-data格式更合适。

 

安全性

平时说GET不如POST安全，因为POST用body传输数据，而GET用url传输，更加容易看到。

但是从攻击的角度，无论是GET还是POST都不够安全，因为HTTP本身是明文协议。每个HTTP请求和返回的每个byte都会在网络上明文传播，不管是url，header还是body。这完全不是一个“是否容易在浏览器地址栏上看到“的问题。

 

HTTPS

为了避免传输中数据被窃取，必须做从客户端到服务器的端端加密。业界的通行做法就是https——即用SSL协议协商出的密钥加密明文的http数据。

如果请求要经过不信任的公网，避免泄密的唯一手段就是https

只要记得一般情况下，私密数据传输用POST + body就好。

编码

中文和特殊符号通过percent encoding编码变成一坨%和16位数字组成的序列，

使用Percent Encoding，即使是binary data，也是可以通过编码后放在URL上的。

这个编码方式只管把字符转换成URL可用字符，但是却不管字符集编码比如中文到底是用UTF8还是GBK）。现在大一统都是用UTF8

尽管在浏览器地址栏可以看到中文。但这种url在发送请求过程中，浏览器会把中文用字符编码+Percent Encode翻译为真正的url，再发给服务器。浏览器地址栏里的中文只是想让用户体验好些而已。