Http:Get、Post、Put、Delete、Head、Options详解

最新推荐文章于 2022-12-24 13:44:09 发布

weixin_34358092

最新推荐文章于 2022-12-24 13:44:09 发布

阅读量139

点赞数

文章标签： java 数据库测试

原文链接：https://my.oschina.net/Clarences/blog/1529241

版权

2019独角兽企业重金招聘Python工程师标准>>>

一、概述

Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。还有两个则为扩展型协议请求方法Head、Options。

二、请求方法含义

Get：GET可以说是最常见的了，它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
Head：HEAD和GET本质是一样的，区别在于HEAD不含有呈现数据，而仅仅是HTTP头信息。有的人可能觉得这个方法没什么用，其实不是这样的。想象一个业务情景：欲判断某个资源是否存在，我们通常使用GET，但这里用HEAD则意义更加明确。
Post：向服务器提交数据。这个方法用途广泛，几乎目前所有的提交操作都是靠这个完成。
Put：这个方法比较少见。HTML表单也不支持这个。本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。
Delete：删除某一个资源。基本上这个也很少见，不过还是有一些地方比如amazon的S3云服务里面就用的这个方法来删除资源。
Options：这个方法很有趣，但极少使用。它用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。

三、请求方法详解

1.Get描述

根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的，提交的数据最多只能是1024字节。

所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。这里安全的含义仅仅是指是非修改信息。
幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等这个概念

幂等（idempotent、idempotence）是一个数学或计算机学概念，常见于抽象代数中。
　　幂等有一下几种定义：

单目运算：如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的，那么我们就称该运算是幂等的。比如绝对值运算就是一个例子，在实数集中，有abs(a)=abs(abs(a))。
双目运算：则要求当参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最大值的函数，有在在实数集中幂等，即max(x,x) = x。

但在实际应用中以上2条规定并没有这么严格。

2.Post描述

根据HTTP规范，POST表示可能修改变服务器上的资源的请求，理论上POST没有限制，可传较大量的数据，IIS4中最大为80KB，IIS5中为100KB。GET和POST的一些原理性的问题。但在实际的做的时候，很多人却没有按照HTTP规范去做，导致这个问题的原因有很多，比如说：

很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。
对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
另外一个是，早期的但是Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计。还有一个较为严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。

以上3点典型地描述了老一套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST，它出来一套支持HTTP规范的新风格，可以参考《RESTful Web Services》。

四、表现形式

1.Get

Get请求

GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1  
Host: api.efxnow.com

Get响应

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>

2.Post

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

Post响应


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>

五、常见状态码

100 Continue：初始的请求已经接受，客户应当继续发送请求的其余部分
101 Switching Protocols：服务器将遵从客户的请求转换到另外一种协议
200 OK：一切正常，对GET和POST请求的应答文档跟在后面
201 Created：服务器已经创建了文档，Location头给出了它的URL。
202 Accepted：已经接受请求，但处理尚未完成。
203 Non-Authoritative Information：文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝
204 No Content：没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的
205 Reset Content：没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容
206 Partial Content：客户发送了一个带有Range头的GET请求，服务器完成了它
300 Multiple Choices：客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently：客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
302 Found：类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。
303 See Other：类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
304 Not Modified：客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
305 Use Proxy：客户请求的文档应该通过Location头所指明的代理服务器提取
307 Temporary Redirect：和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是 POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。
400 Bad Request：请求出现语法错误。
401 Unauthorized：客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
403 Forbidden：资源不可用。
404 Not Found：无法找到指定位置的资源
405 Method Not Allowed：请求方法（GET、POST、HEAD、Delete、PUT、TRACE等）对指定的资源不适用。
406 Not Acceptable：指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容。
407 Proxy Authentication Required：类似于401，表示客户必须先经过代理服务器的授权。
408 Request Timeout：在服务器许可的等待时间内，客户一直没有发出任何请求。客户可以在以后重复同一请求。
409 Conflict：通常和PUT请求有关。由于请求和资源的当前状态相冲突，因此请求不能成功。
410 Gone：所请求的文档已经不再可用，而且服务器不知道应该重定向到哪一个地址。它和404的不同在于，返回407表示文档永久地离开了指定的位置，而404表示由于未知的原因文档不可用。
411 Length Required：服务器不能处理请求，除非客户发送一个Content-Length头。
412 Precondition Failed：请求头中指定的一些前提条件失败。
413 Request Entity Too Large：目标文档的大小超过服务器当前愿意处理的大小。如果服务器认为自己能够稍后再处理该请求，则应该提供一个Retry-After头。
414 Request URI Too Long：URI太长
416 Requested Range Not Satisfiable：服务器不能满足客户在请求中指定的Range头
500 Internal Server Error：服务器遇到了意料不到的情况，不能完成客户的请求
501 Not Implemented：服务器不支持实现请求所需要的功能。例如，客户发出了一个服务器不支持的PUT请求
502 Bad Gateway：服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答
503 Service Unavailable：服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503，服务器返回503时可以提供一个Retry-After头
504 Gateway Timeout：由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答
505 HTTP Version Not Supported：服务器不支持请求中所指明的HTTP版本。