实际上，除了他们的头衔之外，没有什么不同。GET和其他方法之间实际上有一个基本的区别。使用“GET”-Request方法，发送url地址行中的数据，首先用问号分隔，然后用&符号分隔。

但是使用“POST”-request方法，您不能通过url传递数据，而是必须将数据作为请求的所谓“主体”中的对象传递。在服务器端，您必须读取接收到的内容正文，以便获得发送的数据。 但另一方面，当你发送"GET"-Request时，就不可能在body中发送内容。

“GET”只用于获取数据而“POST”用于发布数据的说法是绝对错误的。没有人可以阻止你创建新的内容，删除现有的内容，编辑现有的内容或做任何在后端，基于数据，这是由“GET”请求或由“POST”请求发送。没有人能阻止你在后端编码，用一个"POST"-Request，客户端请求一些数据。

对于请求，无论使用哪种方法，您都调用URL并发送或不发送一些数据来指定，您希望将哪些信息传递给服务器以处理您的请求，然后客户端从服务器获得一个答案。数据可以包含你想要发送的任何东西，后端可以对数据做任何它想做的事情，响应可以包含任何你想要放在那里的信息。

只有这两个基本方法。GET和POST。但使它们不同的是它们的结构，而不是你在后端编写的代码。在后端，您可以使用接收到的数据编写任何您想要的代码。但是使用“POST”请求，你必须在正文中发送/检索数据，而不是在url-addressline中，而使用“GET”请求，你必须在url-addressline中发送/检索数据，而不是在正文中。这是所有。

所有其他的方法，比如"PUT"， "DELETE"等等，它们都有和"POST"相同的结构。

如果你想隐藏一些内容，POST方法主要被使用，因为无论你在url-addressline中写什么，这都将被保存在缓存中，GET-Method与用数据写url-addressline是一样的。因此，如果你想发送敏感数据，不一定总是用户名和密码，但例如一些id或哈希，你不希望显示在url地址行，那么你应该使用POST方法。

此外，URL-Addressline的长度被限制为1024个符号，而“POST”-方法则不受限制。因此，如果数据量较大，则可能无法使用GET-Request发送数据，而需要使用POST-Request。这也是post请求的另一个优点。

但是当您没有复杂的文本要发送时，处理get请求要容易得多。 否则，这是POST方法的另一个优点，使用get方法，您需要对文本进行url编码，以便能够在文本甚至空格中发送一些符号。但是使用POST方法没有任何限制，您的内容不需要以任何方式更改或操作。

PUT是一种将内容“上载”到特定URI或覆盖该URI中已有内容的方法。

另一方面，POST是提交与给定URI相关的数据的一种方式。

参考HTTP RFC

POST被认为是某种工厂类型的方法。您将数据包含在其中以创建您想要的内容，而另一端的任何内容都知道如何使用它。PUT用于更新给定URL上的现有数据，或者当您知道URI将是什么并且它还不存在时创建一些新的东西(与POST相反，POST将创建一些东西并在必要时返回URL)。

Post和Put主要用于发布数据和其他更新数据。但是你可以只对post request做同样的事情。

简单来说，你可以说:

1.HTTP Get:用于获取一个或多个条目

2.HTTP Post:用于创建条目

3.HTTP Put:用于更新条目

4.HTTP补丁:用于部分更新项目

5.HTTP删除:用于删除项目

总结

使用PUT创建或用请求中包含的表示定义的状态替换目标资源的状态。这种标准化的预期效果是幂等的，因此它通知中介，在通信失败的情况下，他们可以重复请求。 否则使用POST(包括创建或替换目标资源以外的资源状态)。其预期效果不规范，中介机构不能依赖任何普遍属性。

参考文献

关于POST和PUT请求方法之间语义差异的最新权威描述在RFC 7231中给出(Roy Fielding, Julian Reschke, 2014):

The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.

换句话说，PUT的预期效果是标准化的(用请求中所包含的表示定义的状态创建或替换目标资源的状态)，因此对所有目标资源都是通用的，而POST的预期效果不是标准化的，因此是特定于每个目标资源的。因此POST可以用于任何事情，包括实现PUT和其他请求方法(GET、HEAD、DELETE、CONNECT、OPTIONS和TRACE)的预期效果。

But it is recommended to always use the more specialized request method rather than POST when applicable because it provides more information to intermediaries for automating information retrieval (since GET, HEAD, OPTIONS, and TRACE are defined as safe), handling communication failure (since GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are defined as idempotent), and optimizing cache performance (since GET and HEAD are defined as cacheable), as explained in It Is Okay to Use POST (Roy Fielding, 2009):

POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT), or any of the other standardized methods that tell intermediaries something more valuable than “this may change something.” The other methods are more valuable to intermediaries because they say something about how failures can be automatically handled and how intermediate caches can optimize their behavior. POST does not have those characteristics, but that doesn’t mean we can live without it. POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”