HTTP POST GET 本质区别详解

本文详细阐述了HTTP协议中GET与POST方法的区别,包括原理、表现形式及HTTP响应等方面,对比了二者在安全性、数据传输等方面的差异。

一 原理区别

    一般在浏览器中输入网址访问资源都是通过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 State Transfer),一套支持HTTP规范的新风格,这里不多说了,可以参考《RESTful Web Services》。

二 表现形式区别

   搞清了两者的原理区别,我们再来看一下他们实际应用中的区别:

    为了理解两者在传输过程中的不同,我们先看一下HTTP协议的格式:

    HTTP请求:

<request line>

<headers>

<blank line>

<request-body>]

在HTTP请求中,第一行必须是一个请求行(request line),用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部(header)小节,用来说明服务器要使用的附加信息。在首部之后是一个空行,再此之后可以添加任意的其他数据[称之为主体(body)]。

GET与POST方法实例:
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
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.com
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之后(就是把数据放置在请求行(request line)中),以?分割URL和传输数据,多个参数用&连接;例如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。Url的编码格式采用的是ASCII码,而不是Unicode,这也就是说你不能在Url中包含任何非ASCII字符,所有非ASCII字符均需要编码再传输,关于Url编码可参考:http://kb.cnblogs.com/page/133765/

  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-site request forgery攻击

(4)Http get,post,soap协议都是在http上运行的
1)get:请求参数是作为一个key/value对的序列(查询字符串)附加到URL上的
        查询字符串的长度受到web浏览器和web服务器的限制(如IE最多支持2048个字符),不适合传输大型数据集同时,它很不安全
2)post:请求参数是在http标题的一个不同部分(名为entity body)传输的,这一部分用来传输表单信息,因此必须将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>
<headers>
<blank line>
[<response-body>]

在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行(status line)通过提供一个状态码来说明所请求的资源情况。 
      
 HTTP响应实例:

HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-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.com

回复

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/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.com
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="https://api.efxnow.com/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.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
    <CancelOrder xmlns="https://api.efxnow.com/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:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
    <CancelOrderResponse xmlns="https://api.efxnow.com/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>
</soap12:Envelope>

<think>嗯,用户这次的问题是关于HTTP协议中GETPOST请求的特征区别。从对话历史来看,用户之前已经了解过HTTP客户端请求端的概念,现在想深入理解两种最常用的HTTP方法。 用户提供的站内引用很有价值,特别是引用[1][2]详细列举了GETPOST的多方面区别。不过需要注意引用[3]提到HEAD方法时有个小错误,HEAD请求其实会产生服务器动作(比如检查资源是否存在),只是不返回消息体。 用户可能正在学习Web开发基础,或者需要解决实际工作中API设计的问题。ta特意强调要了解“特征区别”,说明需要系统性的对比,而不仅仅是零散的知识点。 在组织回答时,我会从六个维度展开:设计目的、参数位置、数据限制、缓存特性、安全性幂等性。其中幂等性是个重要但常被忽视的概念,引用[3]提到了但没深入解释,需要补充说明。 特别要注意的是,用户引用的资料中存在几个需要修正的点: - 关于数据限制:实际并非GET有2KB限制(这是早期浏览器的限制),而是URL长度限制;POST理论上受服务器配置限制 - 安全性:POST并不比GET更安全,只是参数不暴露在URL上,但HTTPS才是真正的安全解决方案 - 幂等性:引用[3]说GETHEAD是“安全方法”正确,但需要强调安全方法不等于无动作 最后生成的三个相关问题都很有实践价值,特别是第二个关于RESTful API设计的问题,能帮助用户把知识应用到实际开发中。</think>### HTTP协议中GETPOST请求的特征及区别 #### 一、核心特征对比 | **维度** | **GET请求** | **POST请求** | |------------------|------------------------------------------|------------------------------------------| | **设计目的** | 获取资源(安全且幂等)[^1][^2] | 提交数据(非幂等,可能修改资源)[^1][^2] | | **参数位置** | URL查询字符串(如 `?name=value`)[^1][^2] | 请求体(Request Body)[^1][^2] | | **数据可见性** | 参数暴露于URL浏览器地址栏可见)[^1] | 参数隐藏于请求体(不可直接查看)[^2] | | **数据长度限制** | 受URL长度限制(通常≤2KB)[^1] | 理论上无限制(实际受服务器配置约束)[^1] | | **缓存行为** | 可被浏览器缓存[^2] | 默认不可缓存[^2] | | **安全性** | 低(参数在URL中易被记录)[^1] | 较高(但仍需HTTPS加密保障)[^1] | | **幂等性** | 幂等(多次请求结果相同)[^3] | 非幂等(可能产生副作用)[^3] | --- #### 二、关键区别详解 1. **设计目的与语义** - **GET**:仅用于**获取数据**,不应改变服务器状态(如查询商品信息)[^2][^3] ```http GET /products?id=123 HTTP/1.1 ``` - **POST**:用于**创建/修改资源**(如提交订单、上传文件)[^1][^2] ```http POST /orders HTTP/1.1 Content-Type: application/json {"product_id": 123, "quantity": 2} ``` 2. **数据传输方式** - **GET参数**:附加在URL后,通过`?key=value&...`传递[^1][^2] *示例*:`https://api.com/search?q=keyword` - **POST参数**:封装在请求体中,支持多种编码(如JSON、表单数据)[^2] ```http POST /login HTTP/1.1 Content-Type: application/x-www-form-urlencoded username=admin&password=123456 ``` 3. **安全性与隐私** - **GET风险**:参数暴露在URL浏览器历史、服务器日志中[^1] *禁止场景*:密码传输、敏感操作 - **POST优势**:参数在请求体中,避免直接暴露(但仍需HTTPS防窃听)[^1] 4. **幂等性差异** - **GET幂等**:多次请求同一URL返回相同结果(如刷新页面)[^3] $$ \text{GET}(R) \rightarrow R \quad \text{(资源状态不变)} $$ - **POST非幂等**:每次请求可能产生新资源(如重复提交订单创建多个订单)[^3] $$ \text{POST}(D) \rightarrow R_{\text{new}} \quad \text{(资源状态改变)} $$ 5. **技术限制** - **GET长度限制**:源于URL长度约束(不同浏览器限制为2KB~8KB)[^1] - **POST无硬限制**:但超大请求可能导致服务器拒绝(需配置`max_post_size`) --- #### 三、典型应用场景 | **请求类型** | **适用场景** | **不适用场景** | |-------------|------------------------------------------|----------------------------| | **GET** | 搜索查询、页面跳转、静态资源加载[^1][^2] | 提交密码、大文件上传、敏感操作 | | **POST** | 用户登录、表单提交、API数据创建[^1][^2] | 纯数据查询(无副作用操作) | > **关键实践建议**: > - 遵循RESTful设计原则:GET用于读操作,POST用于写操作[^2] > - 敏感数据必须用POST+HTTPS传输 > - 幂等操作优先考虑GET(如商品详情查询) --- #### 四、HTTP头部差异示例 **GET请求头**(关注资源获取)[^4]: ```http GET /profile?id=100 HTTP/1.1 Host: example.com Accept: text/html Accept-Language: zh-CN ``` **POST请求头**(关注数据处理)[^4]: ```http POST /update_profile HTTP/1.1 Host: example.com Content-Type: application/json Content-Length: 48 {"name": "张三", "age": 30} ``` 通过以上对比可见,GETPOST本质区别在于**语义而非技术**:GET是"获取"的语义,POST是"提交"的语义[^2]。错误使用(如用GET修改数据)会导致API设计混乱安全隐患。 ---
评论 76
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值