注：本文为个人学习摘录，原文地址为：http://javaeedevelop.iteye.com/blog/1725299
An HTTP request is a class consisting of HTTP style requests, request lines, request methods, request URL, header fields, and body content. The most common methods that are used by a client in an HTTP request are as follows:-
1) GET:- Used when the client is requesting a resource on the Web server.
当客户端向Web服务器请求一个资源的时候使用。
2) HEAD:- Used when the client is requesting some information about a resource but not requesting the resource itself.
当客户端向Web服务器请求一个资源的一些信息而不是资源的全部信息的时候使用。
3) POST:- Used when the client is sending information or data to the server—for example, filling out an online form (i.e. Sends a large amount of complex data to the Web Server).
当客户端向服务端发送信息或者数据的时候使用--例如，表单提交（向Web服务器发送大量的复杂的数据）。
4) PUT:- Used when the client is sending a replacement document or uploading a new document to the Web server under the request URL.
当客户端向Web服务端指定URL发送一个替换的文档或者上传一个新万当的时候使用。
5) DELETE:- Used when the client is trying to delete a document from the Web server, identified by the request URL.
当客户端尝试从Web服务端删除一个由请求URL唯一标识的文档的时候使用。
6) TRACE:- Used when the client is asking the available proxies or intermediate servers changing the request to announce themselves.
当客户端要求可用的代理服务器或者中间服务更改请求来宣布自己的时候使用。
7) OPTIONS:- Used when the client wants to determine other available methods to retrieve or process a document on the Web server.
当客户端想要决定其他可用的方法来检索或者处理Web服务端的一个文档时使用。
8) CONNECT:- Used when the client wants to establish a transparent connection to a remote host, usually to facilitate SSL-encrypted communication (HTTPS) through an HTTP proxy.
当客户端想要确定一个明确的连接到远程主机的时候使用，通常便于通过Http代理服务器进行SSL加密通信（Https）连接使用。
特定的HTTP服务器还能够扩展自定义的方法
9) PATCH：-用于将局部修改应用到资源。
1、The GET Request Method --Get请求方法
The GET method is the simplest and the most frequently used request method. It is used to access the static resources, such as HTML documents and images. GET request can be used to retrieve dynamic information by including query parameters in the request URL. For instance, we can send a parameter name with the URL, such as http://www.domain.com?name=Harsh. In this example, Harsh is the dynamic information sent by including a parameter,name, in the request URL. The Web Server can then access this dynamic information through the “name” parameter.
Get方法是最简单最常用的请求方法。它被用来访问静态资源，比如HTML文档和图片等。Get请求可以通过在请求URL中包含查询参数的方法来检索动态信息。例如，我们可以通过URL发送“name”这个参数(http://www.domain.com?name=Harsh)，在这个例子中，Harsh是通过在请求URL中包含参数“name”的动态的信息。Web服务可以通过这个“name”参数来访问动态信息。
2、The HEAD Request Method -- Head方法
According to Wikipedia “Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.” It is used when the client is requesting some information about a resource but not requesting the resource itself. This means that we have a faster way of checking the headers and some server info for a given resource on the server i.e. checking if a given url is serviceable, a given file exists, etc..Sometimes client might only need to view the header of a response (Content-Type or Content-Length). The client can use the HEAD request method to retrieve the header in such cases. The HEAD method is similar to GET method, except that the server does not return a message body (actual page) in response of the HEAD method.
根据维基百科“要求响应上等同于Get请求，但是没有响应Body（Response Body）。这在检索写在响应头(Response Header)中的信息而不需要传输全部的内容的情况下非常有用。”当客户端请求关于一个资源的一些信息而不是请求全部资源的时候使用Head方法。这意味着我们有一种快速的方式来检查针对服务端上一个给定的资源的头信息和一些服务端信息，检测一个给定的url是否可用、给定的文件是否存在等等。有时客户端仅仅需要查看相应的头信息（Content-Type或者Content-Length）。在此类案例中客户端可以使用HEAD请求方法来检测头信息。HEAD方法与GET方法类似，但是HEAD方法不希望在响应信息中包含Message Body(实际页面)。
3、The POST Request Method--Post方法
The Post method is commonly used for accessing dynamic resources or when a large amount of complex information is to be sent to the server. The Web Server accepts the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI( Uniform Resource Identifier). According to Wikipedia “Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.” The major difference between GET and POST is that in GET the request parameters are transmitted as a query string appended to the request URL, while in POST the request parameters are transmitted within the body of the request.
Post方法一般用来访问动态资源，或者在向服务端发送大量的复杂信息的时候使用。Web服务器接收封装在Request中的实体，作为请求URI唯一标识的资源的附属。根据维基百科“提交数据被处理到唯一标识资源。数据被包含在请求的Body(Request Body)中。这可能会导致创建一个新的资源或者更新已有的资源或者两者兼之。”Get方法和Post方法的主要区别是：在Get方法请求中，请求参数是附加在请求URL最后来传输的，而在Post方法中，请求参数是被包含在请求体（Request Body）中传输的。
The POST request method provides the following functionalities:
1) Providing annotations of the existing resources.
2) Posting a message to a bulletin board, newsgroup, mailing list, or a similar group of articles.
3) Providing a block of data, such as the result of the submitting a form, to a data-handling process.
4) Extending a database through an append operation.
Post请求方法提供了如下功能：
（1）为存在的资源提供注释。
（2）发布信息给公告牌、新闻组、邮件列表或者一组类似的文章。
（3）提供一块数据，例如提交Form表单到数据处理单元的结果。
（4）通过附加操作扩展数据库。
4、The PUT Request method--Put方法
The PUT method stores an entity in the specified Request-URI. The entity is a resource residing on the Web server under the specified Request-URI. If the Request-URI does not point to an existing resource, but is capable of being defined as a new resource by the requesting user, the Web Server can create the resource with that URI. If an existing resource is modified, either the 200(OK) or 204 (No Content) response code should be sent to indicate successful modification of a resource. The Web Server must inform the user via the 201 (Created) responses if a new resource is created. If the resource is not created or modified with the Request-URI, an appropriate error response is generated, which reflects the nature of the problem.
Put方法存储一个实体到指定的请求URI。该实体是Web服务端上指定请求URI下的资源。如果请求URI没有指向一个存在的资源，也能被发出请求的用户定义为一个新的资源，Web服务端将使用该URI创建资源。如果一个已经存在的资源被修改，200（OK）或者204（No Content）响应代码将被发送来表示成功修改资源。如果一个新的资源被创建，Web服务端必须向用户返回201(Created)相应代码。如果指定请求URI没有创建或者修改资源，将产生一个适当的错误响应，以反应问题的性质。
5、The DELETE Request method--Delete方法
The DELETE method requests the Web server to delete the resource identified by the Request-URI. This method may be overridden by human intervention (or other means) on the Web Server. If the response includes an entity describing the status of deletion, the 200(OK) response code specifies that the resource has been deleted successfully. If the response is 202(Accepted), it specifies that the resource has not yet been deleted. Similarly, if the response code is 204 ( No Content), it specifies that the resource has been deleted but the response code does not include an entity.
Delete方法通过请求URI请求Web服务删除指定资源。该方法可能在Web服务端被人为的重写。如果响应信息中包含一个实体描述删除的状态，200（OK）相应代码指出资源已经被成功删除。如果响应代码是202（Accepted）,它指出资源还没有被删除。相似的，如果相应代码是204（No Content），它指出资源已经被删除但是响应代码不包含任何实体。
6、The OPTIONS Request method--Options方法
According to Wikipedia “Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting ‘*‘ instead of a specific resource.”
The OPTION method requests for information about the communication options available on the request/response chain identified by a Request-URI. Responses to this method are not cacheable. This method allows the client to determine the options and /or requirements associated with a resource, or the capabilities of a server. If the OPTIONS method includes an entity body, the media type must be indicated by the content-type field.
根据维基百科“返回服务端针对指定的URL所支持的HTTP请求方法。用“*”代替资源名称，想Web服务器发送Options请求，可以测试服务器功能是否正常运作。"Options方法请求关于可请求URI所表示的请求/响应链上的用的通信选项的信息。该方法的响应信息不能被缓存。该方法允许客户端决定选项和/或要求与一种资源或者服务的功能相关联。如果Options方法包含一个实体，则media类型必须通过Content-Type字段来标明。
7、The TRACE Request method--Trace方法
According to Wikipedia “Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.”
The TRACE method is used to invoke a remote application layer associated with a request message. A TRACE request must not include an entity. A client uses the TRACE method to see the received input at the other end of the request chain and diagnostic or testing information.
根据维基百科“回显服务器收到的请求，这样客户端可以看到（如果有）哪一些改变或者添加已经被中间服务器实现。”Trace方法被用来调用与请求消息相关联的远程应用程序层。Trace请求必须包含一个实体。客户端使用Trace方法看到接收用户输入的请求链和诊断或检测信息的另一端。
http协议是一种在网络中进行文件传送遵循的协议。一种无状态的协议、http协议服务器端不跟浏览器端建立长久的通信连接. 建立http通信之后，服务端将文件内容传送给浏览器端接收就完成一次请求。当然一个页面，往往由多个http请求构成、图片，CSS等资源的请求~可能是一个页面进行多个http请求之后得到的结果。
GET: 发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现据（如HTML文本，或者图片或者视频等）返回给客户端.
POST: 向服务器提交数据.
最直观的区别:
1).GET把参数包含在URL中，POST通过request body传递参数;
2).GET在浏览器回退时是无害的，而POST会再次提交请求;
3).GET产生的URL地址可以被Bookmark，而POST不可以;
4).GET请求会被浏览器主动cache，而POST不会，除非手动设置;
5). GET请求只能进行url编码，而POST支持多种编码方式;
6).GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留;
7).GET请求在URL中传送的参数是有长度限制的，而POST没有限制;
8). 对参数的数据类型，GET只接受ASCII字符，而POST没有限制;
9).GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息;
本质区别:
首先GET和POST请求都是HTTP协议中的两种发送请求的方法,而HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议,HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。
1).虽然理论上GET和POST请求在使用上可以没有区别,但是不同的浏览器(发起http请求)和服务器(接受http请求)会限制单次传送数据了来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，(大多数)浏览器通常都会限制url长度在2K个字节，而(大多数)服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到.
2).GET产生一个TCP数据包;POST产生两个TCP数据包;对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200(返回数据);而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。
GET和POST使用时注意:
1). GET与POST都有自己的语义，不能随便混用。
2). 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
3). 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
之前做的java web项目，基本上只使用get和post的请求方式，但是现在新项目额外增加了put，delete，查了点资料，做个简单的总结。
1、GET-安全且幂等
get请求是用来获取数据的，只是用来查询数据，不对服务器的数据做任何的修改，新增，删除等操作。
在这里我们认为get请求是安全的，以及幂等的。安全就是指不影响服务器的数据，幂等是指同一个请求发送多次返回的结果应该相同。
特点：
get请求会把请求的参数附加在URL后面，这样会产生安全问题，如果是系统的登陆接口采用的get请求，需要对请求的参数做一个加密。
get请求其实本身HTTP协议并没有限制它的URL大小，但是不同的浏览器对其有不同的大小长度限制
2、POST-不安全且不幂等
post请求一般是对服务器的数据做改变，常用来数据的提交，新增操作。
特点：
post请求的请求参数都是请求体中
post请求本身HTTP协议也是没有限制大小的，限制它的是服务器的处理能力
3、PUT-不安全但幂等
put请求与post一样都会改变服务器的数据，但是put的侧重点在于对于数据的修改操作，但是post侧重于对于数据的增加。
4、DELETE-不安全但幂等
delete请求用来删除服务器的资源。
5、OPTIONS
options请求属于浏览器的预检请求，查看服务器是否接受请求，预检通过后，浏览器才会去发get，post，put，delete等请求。至于什么情况下浏览器会发预检请求，浏览器会会将请求分为两类，简单请求与非简单请求，非简单请求会产生预检options请求。
关于options请求具体详细的可以观看另一位作者的这篇文章：https://www.jianshu.com/p/5cf82f092201
另外：这些不同方式的请求形式，只是一种规范定义而已，并不是说get请求无法修改服务器的数据，只是一种规范，比如你也可以所有的请求都通过post方式来访问，实现功能上面没有任何问题，只是说这种做不符合了规范而已，我们平常编码还是尽量符合规范比较好。
转自：https://blog.csdn.net/zhenwei1994/article/details/84399999
转自：
1、GET请求会向数据库发索取数据的请求，从而来获取信息，该请求就像数据库的select操作一样，只是用来查询一下数据，不会修改、增加数据，不会影响资源的内容，即该请求不会产生副作用。无论进行多少次操作，结果都是一样的。
2、与GET不同的是，PUT请求是向服务器端发送数据的，从而改变信息，该请求就像数据库的update操作一样，用来修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。
3、POST请求同PUT请求类似，都是向服务器端发送数据的，但是该请求会改变数据的种类等资源，就像数据库的insert操作一样，会创建新的内容。几乎目前所有的提交操作都是用POST请求的。
4、DELETE请求顾名思义，就是用来删除某一个资源的，该请求就像数据库的delete操作。
就像前面所讲的一样，既然PUT和POST操作都是向服务器端发送数据的，那么两者有什么区别呢。。。POST主要作用在一个集合资源之上的（url），而PUT主要作用在一个具体资源之上的（url/xxx），通俗一下讲就是，如URL可以在客户端确定，那么可使用PUT，否则用POST。
综上所述，我们可理解为以下：
1、POST /url 创建
2、DELETE /url/xxx 删除
3、PUT /url/xxx 更新
4、GET /url/xxx 查看
Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是统一资源定位符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。
1.根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的。
(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET 请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。
* 注意：这里安全的含义仅仅是指是非修改信息。
(2).幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等这个概念：
幂等（idempotent、idempotence）是一个数学或计算机学概念，常见于抽象代数中。
幂等有一下几种定义：
对于单目运算，如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的，那么我们就称该运算是幂等的。比如绝对值运算就是一个例子，在实数集中，有abs(a)=abs(abs(a))。
对于双目运算，则要求当参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最大值的函数，有在在实数集中幂等，即max(x,x) = x。
看完上述解释后，应该可以理解GET幂等的含义了。
但在实际应用中，以上2条规定并没有这么严格。引用别人文章的例子：比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即可。
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》。
说完原理性的问题，我们再从表面现像上面看看GET和POST的区别：
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包的包体中。
2."GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据，IIS4中最大为80KB，IIS5中为100KB"？？！
以上这句是我从其他文章转过来的，其实这样说是错误的，不准确的：
(1).首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。
(2).理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说“POST数据量存在80K/100K的大小限制”是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。
对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。
由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制。我们还需要注意：
1).IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。
2).IIS 6.0默认上传文件的最大大小是4MB。
3).IIS 6.0默认最大请求头是16KB。
IIS 6.0之前没有这些限制。所以上面的80K，100K可能只是默认值而已(注：关于IIS4和IIS5的参数，我还没有确认)，但肯定是可以自己设置的。由于每个版本的IIS对这些参数的默认值都不一样，具体请参考相关的IIS配置文档。
3.在ASP中，服务端获取GET请求参数用Request.QueryString，获取POST请求参数用Request.Form。在JSP中，用request.getParameter(\"XXXX\")来获取，虽然jsp中也有request.getQueryString()方法，但使用起来比较麻烦，比如：传一个test.jsp?name=hyddd&password=hyddd，用request.getQueryString()得到的是：name=hyddd&password=hyddd。在PHP中，可以用$_GET和$_POST分别获取GET和POST中的数据，而$_REQUEST则可以获取GET和POST两种请求中的数据。值得注意的是，JSP中使用request和PHP中使用$_REQUEST都会有隐患，这个下次再写个文章总结。
4.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击。
总结一下，Get是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求，在FORM（表单）中，Method默认为"GET"，实质上，GET和POST只是发送机制不同，并不是一个取一个发！
转自：https://blog.csdn.net/haif_city/article/details/78333213
对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不一定要用PUT和DELETE。
一：Jersey框架，实现了restful风格，常用的注解@GET、@POST、@PUT、@DELETE如下：
@GET：
对应get请求
作用：标识该操作是用于获取服务端的资源，可以理解为select操作
特点：GET方式提交的数据最多只能是2KB字节；数据通过browser地址栏进行传递，用户信息会暴露在browser地址了，不安全
@POST：
对应post请求
作用：用于向服务端新增数据，常用于提交表单。可以理解为insert操作
特点：理论上POST方式，对提交的数据大小没有限制；数据通过http协议的body体中进行传递，不会暴露用户信息，相对安全
@PUT：
对应put请求
作用：用于向服务端更新数据，与post的使用很相似。可以理解为update操作
@DELETE：
对应delete请求
作用：标识该操作是：用于删除服务端的资源，可以理解为delete操作
二：@HEAD：
作用：只请求页面首部，响应报文中没有实体的主体部分(没有body体)
与@GET的区别如图：
三：注：可能在一个操作里，还会涉及到相关联的一系列操作，那么按照最初的操作来定义请求。
eg：修改出生birthDate，应该是对应的put请求；但是又关联修改年龄age，还新增insert或者删除delete关联的数据(可能不符合逻辑)，此时有是post、delete的请求方式。但是我们方法对应的请求只能有一个，我们会使用最初的put请求，因为后面的相关操作都是在修改birthDate的基础上来展开的，我们只需要给出最初的请求方式即可。
对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不一定要用PUT和DELETE。
一：Jersey框架，实现了restful风格，常用的注解@GET、@POST、@PUT、@DELETE如下：
@GET：
对应get请求
作用：标识该操作是用于获取服务端的资源，可以理解为select操作
特点：GET方式提交的数据最多只能是2KB字节；数据通过browser地址栏进行传递，用户信息会暴露在browser地址了，不安全
@POST：
对应post请求
作用：用于向服务端新增数据，常用于提交表单。可以理解为insert操作
特点：理论上POST方式，对提交的数据大小没有限制；数据通过http协议的body体中进行传递，不会暴露用户信息，相对安全
@PUT：
对应put请求
作用：用于向服务端更新数据，与post的使用很相似。可以理解为update操作
@DELETE：
对应delete请求
作用：标识该操作是：用于删除服务端的资源，可以理解为delete操作
二：@HEAD：
作用：只请求页面首部，响应报文中没有实体的主体部分(没有body体)
与@GET的区别如图：
三：注：可能在一个操作里，还会涉及到相关联的一系列操作，那么按照最初的操作来定义请求。
eg：修改出生birthDate，应该是对应的put请求；但是又关联修改年龄age，还新增insert或者删除delete关联的数据(可能不符合逻辑)，此时有是post、delete的请求方式。但是我们方法对应的请求只能有一个，我们会使用最初的put请求，因为后面的相关操作都是在修改birthDate的基础上来展开的，我们只需要给出最初的请求方式即可。
原文地址：https://www.cnblogs.com/abdm-989/p/11929944.html