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,如需转载请自行联系原作者




相关文章
|
JSON API 网络架构
HTTP常见的请求方法、响应状态码、接口规范介绍
本文详细介绍了HTTP常见的请求方法、响应状态码和接口规范。通过理解和掌握这些内容,开发者可以更好地设计和实现W
2681 83
|
安全 网络协议 Linux
Linux网络应用层协议展示:HTTP与HTTPS
此外,必须注意,从HTTP迁移到HTTPS是一项重要且必要的任务,因为这不仅关乎用户信息的安全,也有利于你的网站评级和粉丝的信心。在网络世界中,信息的安全就是一切,选择HTTPS,让您的网站更加安全,使您的用户满意,也使您感到满意。
480 19
HTTP协议探究:常用方法一网打尽
总的来说,HTTP协议的命令犹如一把钥匙,解锁了互联网世界的大门。它是规则,也是工具,了解了它,就等于掌握了互联网的一把通行证。我们每天都在用,也常常无视它,但是只有深刻理解了它,才能更好地运用它。如此,我们的互联网世界旅程就会变得更加顺畅,更加有趣。
330 14
|
网络安全 开发者
如何解决HTTPS协议在WordPress升级后对网站不兼容的问题
以上就是解决WordPress升级后HTTPS协议对网站的不兼容问题的方法。希望能把这个棘手的问题看成是学校的管理问题一样来应对,将复杂的技术问题变得更加有趣和形象,并寻觅出解决问题的方式。希望你的网站能在新的学期得到更好的发展!
392 19
|
JSON 安全 网络协议
HTTP/HTTPS协议(请求响应模型、状态码)
本文简要介绍了HTTP与HTTPS协议的基础知识。HTTP是一种无状态的超文本传输协议,基于TCP/IP,常用80端口,通过请求-响应模型实现客户端与服务器间的通信;HTTPS为HTTP的安全版本,基于SSL/TLS加密技术,使用443端口,确保数据传输的安全性。文中还详细描述了HTTP请求方法(如GET、POST)、请求与响应头字段、状态码分类及意义,并对比了两者在请求-响应模型中的安全性差异。
1239 20
|
网络协议 安全 网络安全
HTTP与HTTPS协议入门
HTTP协议是互联网的基石,HTTPS则是其安全版本。HTTP基于TCP/IP协议,属于应用层协议,不涉及数据包传输细节,主要规定客户端与服务器的通信格式,默认端口为80。
1035 26
HTTP与HTTPS协议入门
|
安全 网络协议 算法
HTTP/HTTPS与SOCKS5协议在隧道代理中的兼容性设计解析
本文系统探讨了构建企业级双协议隧道代理系统的挑战与实现。首先对比HTTP/HTTPS和SOCKS5协议特性,分析其在工作模型、连接管理和加密方式上的差异。接着提出兼容性架构设计,包括双协议接入层与统一隧道内核,通过协议识别模块和分层设计实现高效转换。关键技术部分深入解析协议转换引擎、连接管理策略及加密传输方案,并从性能优化、安全增强到典型应用场景全面展开。最后指出未来发展趋势将更高效、安全与智能。
740 1
|
安全 网络安全 数据安全/隐私保护
HTTP 与 HTTPS 协议及 SSL 证书解析-http和https到底有什么区别?-优雅草卓伊凡
HTTP 与 HTTPS 协议及 SSL 证书解析-http和https到底有什么区别?-优雅草卓伊凡
881 3
|
缓存 安全 API
为什么 HTTP GET 方法不使用请求体?
本指南深入探讨了为什么HTTP GET方法通常不使用请求体,解释了GET方法的主要用途及其设计原则。GET请求旨在通过URL安全、幂等地检索数据,避免因请求体带来的复杂性和潜在问题。尽管HTTP/1.1规范允许GET请求包含请求体,但这并不常见且可能引发副作用。掌握这些原则有助于开发者在API开发中更高效地使用GET请求。
|
API 开发者
了解 HTTP 的PUT 与 POST方法的综合指南
HTTP PUT 和 POST 方法是构建 Web 应用与 API 的核心工具,用于资源的创建与更新。PUT 方法通过指定 URL 更新或创建完整资源,具有幂等性;而 POST 方法更灵活,主要用于创建新资源,但不具备幂等性。本文详细对比了两者在请求体、URL 使用、资源处理等方面的区别,并提供了实际应用示例,帮助开发者根据场景选择合适的方法以优化 API 设计。
1186 13