Post 方法参数写在body中和写在url中有什么区别?

https://www.zhihu.com/question/64312188/answer/370779721
解释之前我们先基于Http协议,根据Http的请求方法对应的数据传输能力把Http请求分为Url类请求和Body类请求,Url类请求包括但不限于GET、HEAD、OPTIONS、TRACE 等请求方法。

Body类请求包括但不限于POST、PUSH、PATCH、DELETE 等请求方法。 在语义上来说,例如GET请求是查询或者获取服务端的资源的,POST请求是向服务器push数据或者创建资源的。其它同类请求方法多少都有点相同的含义,不过它们谁有谁该做的事,例如支持缓存,探测响应头和断点续传等。

Url类请求释义

对于Url类请求,客户端是不能通过body写出数据的,服务端拿到的body是空的。因此一般情况下,我们提供的HttpClient被Url类的请求getOutputStream()的时候会抛一个异常,而HttpServer接受到Url类的请求后getInputStream()的时候也会抛一个异常,这都是为了告诉调用者这是不合理的。

这里的HttpClient和HttpServer不是特指某框架或者浏览器,而是个笼统的称呼。

因此Url类的请求想要提交参数,就把参数跟在url后边了,但是url一般是指向资源的,因此url后面跟的参数更多的是一种条件和要求(例如阿里云OSS处理图片时)。 做了一张url的图,辅助一下:
在这里插入图片描述
看完图应该知道了,其实我们称为参数的这一段整体上叫做Query,把它们拆开后组成键值对的形式又叫做Parameters,大多数情况下一个Key对应一个Value,当然是允许一个Key对应多个Values的。

Body类请求释义

Body类请求在语义和能力上来说应该是兼容Url类请求的,但是根据Http协议它们谁有谁该做的事。例如RESTful风格就是根据Http协议来提出的。

对于Body类请求,客户端可以通过body写出数据,服务端可以通过body接受数据。因此Body类请求能上传到服务端的数据比Url类请求的大的多。

RFC2616没有规定url的最大长度,但是规定当服务器不能处理太长的url时就返回414状态码(Request-URI Too Long),因此几乎可以说URL不能直接传输Binary数据,除非ToString,例如Base64。 Body类请求除了可以把参数放到url中,也可以通过body发送数据。

例如当Content-Type是application/x-www-form-urlencoded时,客户端可以通过body发送键值对数据,例如key1=value1&key2=value2,这就是题主说的那种情况。

Body类请求在语义和能力上来说应该是兼容Url类请求的,但是根据Http协议它们谁有谁该做的事。

例如RESTful风格就是根据Http协议来提出的。 对于Body类请求,客户端可以通过body写出数据,服务端可以通过body接受数据。

因此Body类请求能上传到服务端的数据比Url类请求的大的多。 RFC2616没有规定url的最大长度,但是规定当服务器不能处理太长的url时就返回414状态码(Request-URI Too Long),因此几乎可以说URL不能直接传输Binary数据,除非ToString,例如Base64。

Body类请求除了可以把参数放到url中,也可以通过body发送数据。 例如当Content-Type是application/x-www-form-urlencoded时,客户端可以通过body发送键值对数据,例如key1=value1&key2=value2,这就是题主说的那种情况。

总结

Body类请求在语义和能力上来说应该是兼容Url类请求的,但是根据Http协议它们谁有谁该做的事。例如RESTful风格就是根据Http协议来提出的。 对于Body类请求,客户端可以通过body写出数据,服务端可以通过body接受数据。因此Body类请求能上传到服务端的数据比Url类请求的大的多。 RFC2616没有规定url的最大长度,但是规定当服务器不能处理太长的url时就返回414状态码(Request-URI Too Long),因此几乎可以说URL不能直接传输Binary数据,除非ToString,例如Base64。 Body类请求除了可以把参数放到url中,也可以通过body发送数据。 例如当Content-Type是application/x-www-form-urlencoded时,客户端可以通过body发送键值对数据,例如key1=value1&key2=value2,这就是题主说的那种情况。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值