请注意，自首次编写此答案以来，问题已更改/已得到澄清。对问题的最新迭代的进一步响应是在第二条水平规则之后
HTTP协议中的诸如GET和POST之类的方法有什么需求？
它们以及其他一些信息，例如标头格式，标头和正文如何分离的规则，构成了HTTP协议的基础。
我们不能仅使用请求正文和响应正文来实现HTTP协议吗？
不，因为那样创建的内容都不是HTTP协议
例如，URL将包含请求，该请求将根据服务器端的编程语言（例如Servlet）映射到一个函数，并作为响应发送HTML和JavaScript响应。
恭喜，您刚刚发明了新协议！现在，如果您想建立一个标准机构来驱动和维护，开发它，等等，那么它有一天可能会超过HTTP
我很欣赏这句话，但对于Internet，TCP / IP或服务器与客户端之间进行的通信并没有什么神奇的。您打开一个连接并通过网络发送一些单词，形成对话。如果要理解请求并提供明智的响应，对话实际上必须在两端遵守一些已批准的规范。这与世界上的任何对话都没有什么不同。你说英语，邻居说汉语。希望您的手挥动，指向和拳头摇晃足以传达您的信息，即您不希望他将汽车停在您家门前。
返回互联网，如果您打开了一个与HTTP兼容的Web服务器的套接字并发送以下信息：
EHLO
AUTH LOGIN
（SMTP电子邮件传输的开始），那么您将不会得到明智的答案。您可以制作最完美的SMTP兼容客户端，但是您的Web服务器不会与之对话，因为此对话只涉及共享协议-无共享协议，无聊。
这就是为什么如果不实现HTTP协议就无法实现HTTP协议的原因。如果您编写的内容不符合协议，那么就根本不是协议-它是另外一回事，它将无法按照协议中的规定进行操作
如果我们用您的例子来讨论一下；客户端连接并仅声明类似于URL的位置。服务器理解它并仅发送类似于HTML / JS（网页）的内容，那么可以正常工作。你存了什么？关于不说GET的几个字节？放弃这些令人讨厌的标题的方法很少。服务器也保存了一些标题-但是如果您无法弄清楚它发送给您的内容怎么办？如果您要求输入一个以JPEG结尾的URL，并且它向您发送了一些构成图片的字节，但使用PNG，该怎么办？当时的PNG不完整。如果我们只有一个标头，说它要去多少字节发送，那么我们就会知道接收到的字节数实际上是否是整个文件。如果服务器压缩响应以节省一些带宽却没有告诉您怎么办？您将花费一些可观的计算能力来计算发送的内容。
最终，我们需要元信息-有关信息的信息；我们需要标题；我们需要文件具有名称，扩展名和创建日期。我们需要人们过生日，如要致以问候和感谢，等等-世界上充满了协议和有关上下文的信息，因此我们不必坐下来从头开始工作。它花费了一些存储空间，但是很值得
确实需要实现各种HTTP方法吗？
可以说，人们不必实现整个指定的协议，通常对于任何情况都是如此。我不知道英语中的每个单词；我的中国邻居也是一名软件开发人员，但是在不同的行业中，对于我在该行业中使用的某些术语，他甚至都不了解中文，更不用说英语。不过，好事是，我们俩都可以拿起有关HTTP实现的文档，他可以编写服务器，而我可以编写客户端，并且可以在不同的体系结构上使用不同的编程语言，并且它们仍然有效，因为它们遵循协议
很有可能情况是，您的用户将不会发出除GET请求之外的任何东西，不会使用持久连接，将JSON以外的任何内容作为正文发送，或需要接受除text / plain之外的任何内容，因此您可以编写一个真正精简的Web服务器，该服务器只能满足客户端浏览器非常有限的需求。但是您不能随意决定取消使“某些文本通过套接字”成为HTTP的基本规则。您不能放弃以下基本概念：请求将是一个字符串，例如：
VERB URL VERSION
header: value
maybe_body
响应中将包含一个版本，状态代码以及标题。如果您更改了其中的任何内容-不再是HTTP-则是其他内容，并且只能与旨在理解它的内容一起使用。这些定义就是HTTP的含义，因此，如果要实现HTTP，则必须遵循这些定义
更新资料
您的问题有所发展，以下是对您所提出问题的一些答复：
为什么HTTP协议具有方法概念？
从历史上看，您需要认识到事情在设计和实现上更加僵化，甚至不存在脚本的程度，甚至认为页面可以是动态的，都是在内存中动态生成并向下推套接字的观念。客户端请求并读取并向下推送套接字的磁盘上的静态文件的状态不存在。这样一来，早期的网络就集中在包含链接到其他页面的静态页面的概念上，所有页面都存在于磁盘上，并且导航本来是由终端主要通过URL请求GET请求的，服务器才能进行映射网址到磁盘上的文件并发送。还有一种想法是，相互链接并链接到其他地方的文档网络应该是不断发展的，
这为这些方法提供了一些历史背景-曾几何时，URL是不灵活的位，并且简单地引用磁盘上的页面，因此该方法很有用，因为它允许客户端描述其对文件的意图，而服务器将以某种不同的方式处理该方法。在超文本（实际上仅是文本）网络的原始视觉中，实际上并没有URL是虚拟的或用于切换或映射的概念。
我不希望这个答案成为具有日期的历史记录的文档，并引用了事情何时开始发生变化的确切参考（为此您可能可以阅读Wikipedia），但这足以说明随着时间的推移Web的发展势头越来越大，在服务器-客户端连接的每一端，我们正在扩展创造丰富的多媒体体验的机会。浏览器支持用于格式化内容的大量标签，每个浏览器都在竞相实现必需的媒体丰富功能以及使事物看起来时髦的新方法。
脚本到达客户端，插件和浏览器扩展，所有这些都是为了使浏览器成为功能强大的所有功能。在服务器端，基于算法或数据库数据的内容主动生成是最大的推动力，并且它继续发展到磁盘上几乎没有文件的程度-当然，我们将图片或脚本文件保留为文件Web服务器并具有浏览器GET，但是越来越多的浏览器显示的图片和运行的脚本不是您可以在文件资源管理器中打开的文件，它们是生成的内容，是按需完成的一些编译过程的输出，描述如何绘制像素（而不是像素的位图数组）的SVG或从诸如TypeScript的更高级形式的脚本中发出的JavaScript
在制作现代的数兆字节的页面时，现在大概只有一小部分是磁盘上的固定内容。将数据库数据格式化并整形为HTML，供浏览器使用，并由服务器完成，以响应url以某种方式引用了多个不同的编程例程
我在对问题的评论中提到，这有点像一个完整的圈子。当计算机耗费成千上万个房间时，通常是允许多个用户通过数百个笨拙的终端使用一个超级强大的中央大型机-键盘和鼠标，绿屏，发送一些文本，获取一些信息。发短信。随着时间的推移，随着计算能力的提高和价格的下降，人们开始使用台式计算机，而台式计算机的功能要比早期大型机强大，并且可以在本地运行强大的应用程序，因此大型机模型已经过时了。不过，它从未消失，因为事情发展了另一种方式，并在某种程度上恢复为提供大多数有用的应用程序功能的中央服务器，以及数百台客户端计算机，它们只在屏幕上绘图，几乎没有什么作用，并向服务器提交数据或从服务器接收数据。在这段过渡时期内，您的计算机足够聪明，可以同时运行自己的单词和Outlook副本，这又再次让位给了在线办公，您的浏览器是一种用于在屏幕上绘制图片并编辑您的文档/电子邮件的设备重新编写为驻留在服务器上的东西，然后将其保存在服务器上，发送给其他用户并与其他用户共享，这是因为浏览器只是一个外壳，可在任何时候提供部分视图，而该东西驻留在其他地方
从答案中，我对为什么有方法的概念有了一定的了解。这引出了另一个相关的问题：
例如，在gmail compose链接中，将发送PUT / POST请求和数据。浏览器如何知道要使用哪种方法？
默认情况下，它使用GET，按照约定/规范，因为这是您键入url并按return时将发生的命令
服务器发送的gmail页面是否包含调用gmail compose请求时要使用的方法名称？
这是我在上面的评论中提到的关键内容之一。在现代网络中，页面甚至都不再相关。一旦页面成为磁盘上的文件，浏览器就会获取。然后，它们变成了主要通过将数据放入模板中而动态生成的页面。但是它仍然涉及“从服务器请求新页面，获取页面，显示页面”的过程。页面交换真的很流畅；您没有看到它们加载，调整大小和颠簸它们的布局，因此看上去更平滑，但仍然是浏览器用另一个页面替换整个页面或页面的一部分
现代的做事方式是使用单页应用程序。浏览器在内存中有一个以某种方式显示的文档，脚本调用了thebservr并获取了一些信息，然后对文档进行了处理，以使页面的一部分以可视方式更改以显示新信息-整个过程不会浏览器曾经加载另一个新页面；它只是成为一个UI，其中的部分内容就像典型的客户端应用程序（如word或Outlook）一样进行更新。新元素会出现在其他元素的顶部，并且可以在模拟对话框窗口等周围拖动。所有这些都是浏览器脚本引擎使用开发人员想要的任何http方法发送请求，取回数据并查看浏览器正在绘制的文档。您可以认为现代浏览器是一种出色的设备，类似于整个操作系统或虚拟计算机。一种可编程设备，具有相当标准化的方式来在屏幕上绘制事物，播放声音，捕获用户输入并将其发送进行处理。使它绘制UI所需要做的就是为它提供一些html / css，使它成为UI，然后不断调整html以使浏览器更改其绘制的内容。哎呀，人们习惯于看到地址栏的更改/将其用作意图的方向，即使没有导航（请求整个新页面），单个页面的应用程序也会以编程方式更改网址 使它绘制UI所需要做的就是为它提供一些html / css，使它成为UI，然后不断调整html以使浏览器更改其绘制的内容。哎呀，人们习惯于看到地址栏的更改/将其用作意图的方向，即使没有导航（请求整个新页面），单个页面的应用程序也会以编程方式更改网址 使它绘制UI所需要做的就是为它提供一些html / css，使它成为UI，然后不断调整html以使浏览器更改其绘制的内容。哎呀，人们习惯于看到地址栏的更改/将其用作意图的方向，即使没有导航（请求整个新页面），单个页面的应用程序也会以编程方式更改网址
当我们调用www.gmail.com时，必须使用GET方法，浏览器如何知道要使用此方法？
真正。因为它是指定的。第一个请求是因为它一直以来都是-获取一些初始html来绘制UI，然后永久性地对其进行戳戳和操作，或者使用其他脚本来获取另一个页面以进行戳戳和操作并制作响应式UI
就像一些答案说的那样，我们可以在DELETE方法上创建新用户，这引起了对HTTP协议中方法概念背后的意图的质疑，因为归根结底，这完全取决于服务器他们要将URL映射到什么功能。 。客户为什么要告诉服务器URL使用什么方法。
历史。遗产。从理论上讲，我们明天可以扔掉所有的http方法-我们处于编程成熟度级别，在这里，方法已经过时了，因为URL是可处理的，在某种程度上它们可以作为向服务器指示要保存数据的切换机制。正文作为草稿电子邮件，或删除草稿-服务器上没有/ emails / draft / save / 1234文件-对该服务器进行了编程，可以将网址分开，并知道如何处理正文数据-保存它作为ID为1234的草稿电子邮件
因此，除了方法产生的巨大的遗留兼容性之外，当然可以取消方法。最好仅将它们用于所需的内容，而在很大程度上忽略它们，而使用所需的任何东西使它们正常工作。我们仍然需要如此高级的方法，因为您必须记住，它们对于我们创建应用程序的浏览器和服务器都具有重要意义。客户端脚本希望使用基础浏览器发送数据，它需要使用一种方法来使浏览器按其要求进行操作-可能是POST，因为GET将其所有变量信息打包到url中，并且具有长度限制在很多服务器上。客户端需要服务器的长响应-不要使用HEAD，因为根本不应该具有响应主体。