Http协议的Delete和Put方法是做什么的?怎么用?

简介:
一般来说,Web服务器默认的只支持Post和Get这两种“只读”的请求方法。但是随着Ajax XMLHttpRequest 和 REST风格应用的深入,我们发现Http 1.1协议还支持如下请求方法(Request Method):
OPTIONS
HEAD
DELETE
PUT
TRACE
CONNECT
Get是最常用的,就是向Web Server发请求“获取”资源;那么Post就是向Web Server“邮寄”一些封装的数据包获取资源,这两者方法严格的说都是“索取”行为。
顾名思义,Delete方法就是通过http请求删除指定的URL上的资源啦,Delete请求一般会返回3种状态码:
200 (OK) - 删除成功,同时返回已经删除的资源 
202 (Accepted) - 删除请求已经接受,但没有被立即执行(资源也许已经被转移到了待删除区域) 
204 (No Content) - 删除请求已经被执行,但是没有返回资源(也许是请求删除不存在的资源造成的) 
Put方法就不多废话了,就是往Web Server上直接扔资源(上传资源)嘛,不过实际操作起来可能会让诸位看官喝一壶,E文定义如下:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,
it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.
HTTP/1.1 does not define how a PUT method affects the state of an origin server.
PUT requests MUST obey the message transmission requirements set out in section 8.2.
Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.
上面说的都是虚的,实战才是硬道理!
(本文始发于CSDN,作者胡奇的博客: http://blog.csdn.net/kthq )
首先,我们要让Web Server支持Delete 和 Put请求方法,以大家熟悉的Tomcat为例: 
在Tomcat的web.xml 文件中配置 org.apache.catalina.servlets.DefaultServlet 的初始化参数
<init-param>  
    <param-name>readonly</param-name>  
    <param-value>false</param-value> 
</init-param>
readonly参数默认是true,即不允许delete和put操作,所以默认的通过XMLHttpRequest对象的put或者delete方法访问就会报告 http 403 forbidden 错误。
接下来,从客户端通过 Ajax XMLHTTPRequest 发起 DELETE/PUT 请求: 
function getXMLHTTPRequest(){
    if (XMLHttpRequest)    {
        return new XMLHttpRequest();
    } else {
        try{
            return new ActiveXObject('Msxml2.XMLHTTP');
        }catch(e){
            return new ActiveXObject('Microsoft.XMLHTTP');
        }
    }
}
var req = getXMLHTTPRequest();
req.open('DELETE','http://localhost/test.jsp',false);
req.send(null);
document.write(req.responseText);
WebDAV也需要使用到这2种Http请求方法。


     本文转自胡奇 51CTO博客,原文链接:http://blog.51cto.com/huqicto/280671,如需转载请自行联系原作者




相关文章
|
28天前
|
缓存 负载均衡 网络协议
HTTP 与 SOCKS5 代理协议:企业级选型指南与工程化实践
面向企业网络与数据团队的代理协议选型与治理指南,基于流量特征选择HTTP或SOCKS5协议,通过多协议网关统一出站,结合托管网络降低复杂度,实现稳定吞吐、可预测时延与合规落地。
|
3月前
HTTP协议中请求方式GET 与 POST 什么区别 ?
GET和POST的主要区别在于参数传递方式、安全性和应用场景。GET通过URL传递参数,长度受限且安全性较低,适合获取数据;而POST通过请求体传递参数,安全性更高,适合提交数据。
509 2
|
3月前
|
应用服务中间件
HTTP协议中常见的状态码
HTTP协议状态码分为1xx、2xx、3xx、4xx、5xx五类,常见状态码包括:101(请求已接受)、200(请求成功)、302(重定向)、400(请求错误)、401(未认证)、403(无权限)、404(资源不存在),以及500(服务器错误)、502(网关错误)、503(服务不可用)、504(网关超时)等。
128 0
|
3月前
|
网络协议 安全 网络安全
什么是HTTP协议
HTTP协议是超文本传输协议,基于TCP,规定了客户端与服务器端通信规则,但数据以明文传输,安全性低。HTTPS则通过SSL加密保障数据安全。两者默认端口不同,HTTP为80,HTTPS为443。HTTPS安全性更高,但消耗更多服务器资源。
172 0
|
3月前
|
数据采集 Web App开发 JSON
Python爬虫基本原理与HTTP协议详解:从入门到实践
本文介绍了Python爬虫的核心知识,涵盖HTTP协议基础、请求与响应流程、常用库(如requests、BeautifulSoup)、反爬应对策略及实战案例(如爬取豆瓣电影Top250),帮助读者系统掌握数据采集技能。
263 0
|
3月前
|
缓存 网络协议 UED
深度解析HTTP协议从版本0.9至3.0的演进和特性。
总的来说,HTTP的演进是互联网技术不断发展和需求日益增长的结果。每一次重要更新都旨在优化性能,增进用户体验,适应新的应用场景,而且保证了向后兼容,让互联网的基础架构得以稳定发展。随着网络技术继续进步,我们可以预期HTTP协议在未来还会继续演化。
423 0
|
XML 缓存 算法
HTTP协议详解
HTTP协议详解
767 1
HTTP协议详解
|
Web App开发 网络协议 .NET
第206天:http协议终极详解---看这一篇就够了
HTTP简介 HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。
3806 0
|
Web App开发 缓存 前端开发
HTTP协议详解
当今web程序的开发技术真是百家争鸣,ASP.NET, PHP, JSP,Perl, AJAX 等等。 无论Web技术在未来如何发展,理解Web程序之间通信的基本协议相当重要, 因为它让我们理解了Web应用程序的内部工作. 本文将对HTTP协议进行详细的实例讲解,内容较多,希望大家耐心看。
1392 0