Get,Post请求⽅式经典详解
本⽂转⾃：blog.csdn/findsafety/article/details/47129021
前⼏天⼯作中，所有表单我都采⽤post⽅法，头⼉说那样不好，⼤型⽹站上⼀般都采⽤get⽅法，不理解。
在⽹上摘到⼀段⽐较有⽤的话
减低服务器流量压⼒
根据 HTTP 规范，GET ⽤于信息获取，⽽且应该是安全的和幂等的。所谓安全的意味着该操作⽤于获取信息⽽⾮修改信息。换句话
说，GET 请求⼀般不应产⽣副作⽤。幂等的意味着对同⼀ URL 的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。从根本上讲，其⽬标是当⽤户打开⼀个链接时，她可以确信从⾃⾝的⾓度来看没有改变资源。⽐如，新闻站点的头版不断更新。虽然第⼆次请求会返回不同的⼀批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。反之亦然。POST 请求就不那么轻松了。POST 表⽰可能改变服务器上的资源的请求。仍然以新闻站点为例，读者对⽂章的注解应该通过 POST 请求实现，因为在注解提交之后站点已经不同了（⽐⽅说⽂章下⾯出现⼀条注解）
还不是很明⽩，下午我们探讨⼀下Http中get post的本质区别
⼀原理区别
⼀般在浏览器中输⼊⽹址访问资源都是通过GET⽅式；在FORM提交中，可以通过Method指定提交⽅式为GET或者POST，默认为GET提交
Http定义了与服务器交互的不同⽅法，最基本的⽅法有4种，分别是GET，POST，PUT，DELETE
URL全称是资源描述符，我们可以这样认为：⼀个URL地址，它⽤于描述⼀个⽹络上的资源，⽽HTTP中的GET，POST，PUT，DELETE 就对应着对这个资源的查，改，增，删 4个操作。到这⾥，⼤家应该有个⼤概的了解了，GET⼀般⽤于获取/查询资源信息，⽽POST⼀般⽤于更新资源信息(个⼈认为这是GET和POST的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异)。
根据HTTP规范，GET⽤于信息获取，⽽且应该是安全的和幂等的。
1.所谓安全的意味着该操作⽤于获取信息⽽⾮修改信息。换句话说，GET请求⼀般不应产⽣副作⽤。就是说，它仅仅是获取资源信息，就像数据库查询⼀样，不会修改，增加数据，不会影响资源的状态。
* 注意：这⾥安全的含义仅仅是指是⾮修改信息。
2.幂等的意味着对同⼀URL的多个请求应该返回同样的结果。这⾥我再解释⼀下幂等这个概念：
幂等（idempotent、idempotence）是⼀个数学或计算机学概念，常见于抽象代数中。
幂等有以下⼏种定义：
对于单⽬运算，如果⼀个运算对于在范围内的所有的⼀个数多次进⾏该运算所得的结果和进⾏⼀次该运算所得的结果是⼀样的，那么我们就称该运算是幂等的。⽐如绝对值运算就是⼀个例⼦，在实数集中，有abs(a) = abs(abs(a)) 。
对于双⽬运算，则要求当参与运算的两个值是等值的情况下，如果满⾜运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最⼤值的函数，有在实数集中幂等，即max(x,x) = x 。
看完上述解释后，应该可以理解GET幂等的含义了。
但在实际应⽤中，以上2条规定并没有这么严格。引⽤别⼈⽂章的例⼦：⽐如，新闻站点的头版不断更新。虽然第⼆次请求会返回不同的⼀批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果⽬标是当⽤户打开⼀个链接时，他可以确信从⾃⾝的⾓度来看没有改变资源即可。
根据HTTP规范，POST表⽰可能修改变服务器上的资源的请求。继续引⽤上⾯的例⼦：还是新闻以⽹站为例，读者对新闻发表⾃⼰的评论应该通过POST实现，因为在评论提交后站点的资源已经不同了，
或者说资源被修改了。
上⾯⼤概说了⼀下HTTP规范中，GET和POST的⼀些原理性的问题。但在实际的做的时候，很多⼈却没有按照HTTP规范去做，导致这个问题的原因有很多，⽐如说：
1.很多⼈贪⽅便，更新资源时⽤了GET，因为⽤POST必须要到FORM（表单），这样会⿇烦⼀点。
2.对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要⽤到PUT和DELETE。
3.另外⼀个是，早期的但是Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计。还有⼀个较为严重的问题是传统的Web MVC框架基本上都只⽀持GET和POST两种HTTP⽅法，⽽不⽀持PUT和DELETE⽅法。
* 简单解释⼀下MVC：MVC本来是存在于Desktop程序中的，M是指数据模型，V是指⽤户界⾯，C则是控制器。使⽤MVC的⽬的是将M 和V的实现代码分离，从⽽使同⼀个程序可以使⽤不同的表现形式。
以上3点典型地描述了⽼⼀套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST(Representational StateTransfer)，⼀套⽀持HTTP规范的新风格，这⾥不多说了，可以参考《RESTful Web Services》。
⼆表现形式区别
搞清了两者的原理区别，我们再来看⼀下他们实际应⽤中的区别：
为了理解两者在传输过程中的不同，我们先看⼀下HTTP协议的格式：
HTTP请求：
<request line> //http请求⾏
<headers> //http请求消息报头
<blank line> //回车换⾏
[<request-body>] //http请求正⽂
在HTTP请求中，第⼀⾏必须是⼀个请求⾏（requestline），⽤来说明请求类型、要访问的资源以及使⽤的HTTP版本。紧接着是⼀个⾸部（header）⼩节，⽤来说明服务器要使⽤的附加信息。在⾸部之后是⼀个空⾏，再此之后可以添加任意的其他数据[称之为主体（body）]。
GET与POST⽅法实例：
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive
POST / HTTP/1.1
Host: www.wrox
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
（----此处空⼀⾏----）
name=Professional%20Ajax&publisher=Wiley
有了以上对HTTP请求的了解和⽰例，我们再来看两种提交⽅式的区别：
（1）GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数⽤&连接；例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英⽂字母/数字，原样发送，如果是空格，转换为+，如果是中⽂/其他字符，则直接把字符串⽤BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表⽰的ASCII。
POST提交：把提交的数据放置在是HTTP包的包体中。上⽂⽰例中红⾊字体标明的就是实际的传输数据
因此，GET提交的数据会在地址栏中显⽰出来，⽽POST提交，地址栏不会改变
(2)传输数据的⼤⼩：⾸先声明：HTTP协议没有对传输的数据⼤⼩进⾏限制，HTTP协议规范也没有对URL长度进⾏限制。
⽽在实际开发中存在的限制主要有：
GET：特定浏览器和服务器对URL长度有限制，例如 IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的⽀持。
因此对于GET提交时，传输数据就会受到URL长度的限制。
POST：由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据⼤⼩进⾏限制，Apache、IIS6都有各⾃的配置。
(3)安全性：
POST的安全性要⽐GET的安全性⾼。注意：这⾥所说的安全性和上⾯GET提到的“安全”不是同个概念。上⾯“安全”的含义仅仅是不作数据修改，⽽这⾥安全的含义是真正的Security的含义，⽐如：通过GET提交数据，⽤户名和密码将明⽂出现在URL上，因为(1)登录页⾯有可能被浏览器缓存，(2)其他⼈查看浏览器的历史纪录，那么别⼈就可以拿到你的账号和密码了，除此之外，使⽤GET提交数据还可能会造成Cross-siterequest forgery攻击
（4）Http get,post,soap协议都是在http上运⾏的
1）get：请求参数是作为⼀个key/value对的序列（查询字符串）附加到URL上的
查询字符串的长度受到web浏览器和web服务器的限制（如IE最多⽀持2048个字符），不适合传输⼤型数据集同时，它很不安全
2）post：请求参数是在http标题的⼀个不同部分（名为entitybody）传输的，这⼀部分⽤来传输表单信息，因此必须将Content-type设置为:application/x-www-form-urlencoded。post设计⽤来⽀持web窗体上的⽤户字段，其参数也是作为key/value对传输。
但是：它不⽀持复杂数据类型，因为post没有定义传输数据结构的语义和规则。
3）soap：是http post的⼀个专⽤版本，遵循⼀种特殊的xml消息格式
Content-type设置为: text/xml 任何数据都可以xml化
三 HTTP响应
1．HTTP响应格式：
<status line> //http响应状态⾏
<headers> //http响应消息报头
<blank line> //回车换⾏
[<response-body>] //http响应正⽂
在响应中唯⼀真正的区别在于第⼀⾏中⽤状态信息代替了请求信息。状态⾏（status line）通过提供⼀个状态码来说明所请求的资源情况。HTTP响应实例：
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1Content-Length: 122
＜html＞
＜head＞
＜title＞Wrox Homepage＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞
2．最常⽤的状态码有：
◆200 (OK): 到了该资源，并且⼀切正常。
◆304 (NOT MODIFIED): 该资源在上次请求之后没有任何修改。这通常⽤于浏览器的缓存机制。
◆401 (UNAUTHORIZED): 客户端⽆权访问该资源。这通常会使得浏览器要求⽤户输⼊⽤户名和密码，以登录到服务器。
◆403 (FORBIDDEN): 客户端未能获得授权。这通常是在401之后输⼊了不正确的⽤户名或密码。
◆404 (NOT FOUND): 在指定的位置不存在所申请的资源。
四完整⽰例：
例⼦：
HTTP GET
发送
GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow
回复
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="api.efxnow/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
HTTP POST
发送
POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow
Content-Type: application/x-www-form-urlencoded
Content-Length: length
UserID=string&PWD=string&OrderConfirmation=string
回复
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="api.efxnow/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
SOAP 1.2
发送
POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelopexmlns:xsi="/2001/XMLSchema-
instance"xmlns:xsd="/2001/XMLSchema"xmlns:soap12="/2003/05/soap-envelope"> <soap12:Body>
<CancelOrder xmlns="api.efxnow/webservices2.3">
<UserID>string</UserID>
<PWD>string</PWD>
<OrderConfirmation>string</OrderConfirmation>
</CancelOrder>
</soap12:Body>
</soap12:Envelope>
回复
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelopexmlns:xsi="/2001/XMLSchema-
instance"xmlns:xsd="/2001/XMLSchema"xmlns:soap12="/2003/05/soap-envelope"> <soap12:Body>
<CancelOrderResponse xmlns="api.efxnow/webservices2.3">
<CancelOrderResult>
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</CancelOrderResult>
</CancelOrderResponse>
</soap12:Body>
字符串长度web</soap12:Envelope>
本⽂转⾃：hi.baidu/eveready/blog/item/585bbb30fbcee915eac4af27.html
1. get是从服务器上获取数据，post是向服务器传送数据。
get 和 post只是⼀种传递数据的⽅式，get也可以把数据传到服务器，他们的本质都是发送请求和接收结果。只是组织格式和数据量上⾯有差别，http协议⾥⾯有介绍
<是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段⼀⼀对应，在URL中可以看到。post是通过HTTPpost机制，将表单内各个字段与其内容放置在HTML HEADER内⼀
起传送到ACTION属性所指的URL地址。⽤户看不到这个过程。
因为get设计成传输⼩数据，⽽且最好是不修改服务器的数据，所以浏览器⼀般都在地址栏⾥⾯可以看到，但post⼀般都⽤来传递⼤数据，或⽐较隐私的数据，所以在地址栏看不到，能不能看到不是协议规定，是浏览器规定的。
3. 对于get⽅式，服务器端⽤Request.QueryString获取变量的值，对于post⽅式，服务器端⽤Request.Form获取提交的数据。
没明⽩，怎么获得变量和你的服务器有关，和get或post⽆关，服务器都对这些请求做了封装
4. get传送的数据量较⼩，不能⼤于2KB。post传送的数据量较⼤，⼀般被默认为不受限制。但理论上，IIS4中最⼤量为80KB，IIS5中为100KB。
post基本没有限制，我想⼤家都上传过⽂件，都是⽤post⽅式的。只不过要修改form⾥⾯的那个type参数
5. get安全性⾮常低，post安全性较⾼。
如果没有加密，他们安全级别都是⼀样的，随便⼀个都可以把所有的数据监听到，不信你⾃⼰下⼀个监听⽹络资源的软件，
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论