HTTP请求中的参数提交

Posted 2023-03-03

参考技术A

对于这个问题，相信很多人都能给出一个标准的答案，就像下面列出的几条：

这里列出的几点可能还不全，但涵盖了GET和POST主要的几点区别。我此前也是像这样表面地理解GET和POST请求的，不过最近在使用Postman时让我产生了一些疑惑。
这里提交一个简单的GET请求，正常情况参数我们都是在Query Params中添加，就像下图这样：

这种情况下请求的参数是在url中的，和我们所认知的GET请求是一致的，通过查看请求报文信息也能看出，该请求是没有请求体的。

如果我们把参数放到请求体中提交会怎么样呢？这次我们在body中添加参数，格式先选择 application/x-www-form-urlencoded ，后面我会具体解释这个属性的意义。

这种情况下依然可以请求成功得到响应数据，此时参数没有体现在url中，查看请求报文后发现参数确实是在请求体中的。

这种情况和我们所认知的GET请求就不太一样了，GET请求竟然也能通过请求体来提交参数。
接下来我又测试了一下POST请求，发现请求参数既可以通过请求体来提交，也能像GET请求那样拼接在url后面来提交。
这让我很困惑，看起来GET请求和POST好像没有区别，后来通过 GET和POST两种基本请求方法的区别 这篇文章我找到了答案。HTTP协议的底层是TCP/IP，所以GET和POST请求的底层也是TCP/IP，都是TCP链接，它们能做的事情是一样的。所以， GET请求通过请求体提交参数，POST请求通过url提交参数，在技术上是完全行的通的。
这篇文章中使用的一个比喻很是贴切，这里直接引用一下，在网络世界中，将TCP比作汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET、 POST、 PUT、DELETE等等，HTTP规定当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里（请求体中）。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。
对于GET请求参数的大小限制，我们知道是由于url长度的限制导致的，但其实url的长度并不是GET请求限制的，而是特定的浏览器及服务器的限制，将不同的浏览器和服务器比作不同的运输公司，虽然理论上可以在车顶上无限地堆货物（url中无限加参数），但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url，超过的部分恕不处理。 因此使用POST请求通过url传递参数并不能保证参数一定能被接收到 。同理，如果你用GET请求，在请求体中偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以， 虽然GET请求可以使用请求体提交参数，也不能保证参数一定能被接收到 。
总结一下可以得出结论，GET请求和POST请求本质上是一样的，GET请求通过请求体提交参数和POST请求通过url提交参数都是可行的，但是并不推荐这样做，因为并不能保证服务器可以接受到这种方式传递的参数。
此外，这篇文章还提出了GET请求和POST请求的另一点区别，我们可能知道POST请求要比GET请求慢一下，这是什么原因导致的呢？因为 GET请求产生一个TCP数据包，而POST请求会产生两个TCP数据包 。对于GET请求，浏览器会把Http header和data一并发送出去，服务器响应200（ok）；而对于POST请求，浏览器先发送header，服务器响应100（continue），浏览器再发送data。正是因为POST请求会发送两次包，所以相对会慢一些。但是需要注意，并不是所有浏览器都会在POST请求中发送两次包，Firefox就只发送一次。

我们知道HTTP Header中有一个Content-Type属性，表示请求或响应中的数据格式。根据此前的分析，GET请求一般都是通过url传递参数的，因此没有请求体，除非显式设置，否则请求头中没有Content-Type字段。而POST请求则要通过请求体提交参数，因此请求头中会有Content-Type字段，因此后面的示例都采用POST请求。
Content-Type在Header中的格式如下：

下面就让我们来看一下HTTP中常见的几种Content-Type。

这是最常见的数据编码格式，请求参数被编码成键值对格式，例如key1=val1&key2=val2，中文或特殊字符如"/"、","、“:" 等会自动进行URL转码。不支持文件，一般用于表单提交。结合Postman来看一下：

POST请求提交普通的参数（不含文件）一般都是采用这种数据格式。

这种方式多用于POST请求上传文件，我们依然通过Postman来看一下：

可以看到Content-Type有些不同，在multipart/form-data后面还拼接了一个boundary，它的作用是分割不同的请求参数。在请求实体里每个参数对应一个块，以boundary分割符开始，下一行是 Content-Disposition ，包含了参数类型和参数名，这里的类型是form-data，表示是表单上传，如果参数是文件还会有一个filename参数，值就是文件名称。在这之后有一个空行，最后是参数的值。请求体的最后也会以boundary作为结束的标识。

表示提交的数据是一段Json字符串，服务端/客户端接收到请求/响应时再按照Json格式进行解析。

还有几个相似的类型，比如 application/xml 表示传递xml格式数据； text/plain 表示直接上传一段纯文本等等，这些都属于上传文本信息，区别只是文本格式不同。
上面的示例中展示的都是请求头中的Content-Type，在响应头中也会有Content-Type字段，表示响应数据的格式。在移动开发中，我们请求服务端返回的响应数据一般都是json字符串，Content-Type基本上都是application/json，也有返回text/*类型的（ * 可以是任意类型），本质上返回的数据都是文本，区别只是文本格式不同，使用Postman可以看出区别，对于Content-Type=application/json，Postman会将Json文本自动格式化，而对于Content-Type=text/plain，返回数据不会做任何处理，就是一段纯文本。

由于我不是很懂服务端开发，所以并没有过多关注过响应的Content-Type，有些地方可能说得不对，欢迎大家指正。
Content-Type的种类还有很多，大多数我们在开发中可能并不会用到，感兴趣的话可以查看 HTTP content-type 对照表 。

1.GET请求和POST请求本质上是一样的，参数都可以通过url或者请求体来提交，但是并不能确保参数都可以收到。在实际开发中，除非遇到特殊情况，GET请求使用url传递参数，POST请求参数通过请求体提交。
2.Content-Type决定了数据在请求体/响应体中的格式。对于GET请求，一般无需指定Content-Type；对于POST请求，需要根据提交的参数类型来指定对应的Content-Type。

GET和POST两种基本请求方法的区别
Content-Type 详解