HTTP协议中诸如GET和POST之类的方法有什么需求？

#1 楼

请注意，自从首次撰写此答案以来，问题已更改/已澄清。对第二个水平规则的进一步回答是在第二个水平规则之后


HTTP协议中需要诸如GET和POST之类的方法吗？


它们以及其他一些信息，例如标头格式，标头和正文分离方式的规则，构成了HTTP协议的基础。


我们不能实现HTTP协议仅使用请求正文和响应正文吗？


否，因为那样创建的内容都不是HTTP协议


例如，URL将包含请求，该请求将根据服务器端的编程语言（例如Servlet）映射到一个函数，并作为响应发送HTML和JavaScript响应。


恭喜，您刚刚发明了新协议！现在，如果您想建立一个标准机构来驱动和维护，开发等，它有一天可能会超过HTTP。

我很高兴这有点舌头，但没什么神奇的Internet，TCP / IP或服务器与客户端之间进行的通信。您打开一个连接并通过网络发送一些单词，形成对话。如果要理解请求并传递明智的响应，对话实际上必须在两端遵守一些已批准的规范。这与世界上任何对话都没有什么不同。你说英语，邻居说中文。希望您的手挥手，指向和拳头摇晃足以传达您的信息，即您不希望他将汽车停在您的房屋前。

如果您打开与HTTP兼容的Web服务器的套接字，然后发送以下内容，请返回Internet：
（开始SMTP电子邮件传输），那么您将不会得到明智的答案。您可以制作最完美的SMTP兼容客户端，但是您的网络服务器不会与之对话，因为此对话的全部目的在于共享协议-没有共享协议，没有乐趣。

这就是为什么您可以这样做t实现HTTP协议而不实现HTTP协议；如果您编写的内容不符合协议，那么就根本不是协议-它是另外一回事，它将无法按照协议中的说明进行操作

如果我们使用您的示例运行时刻;客户端连接并仅声明类似于URL的位置。服务器理解它并仅发送类似于HTML / JS（网页）的内容，那么可以正常工作。你存了什么？关于不说GET的几个字节？放弃这些讨厌的头文件的方法很少。服务器也保存了一些头文件-但是如果您无法弄清楚它发送给您的内容怎么办？如果您要求一个以JPEG结尾的URL，并且它向您发送了一些构成图片的字节，但它是PNG，该怎么办？当时的PNG不完整。如果只有一个标头说明要发送多少个字节，那么我们就会知道接收到的字节数实际上是否是整个文件。如果服务器压缩响应以节省一些带宽却没有告诉您怎么办？您将花费一些可观的计算能力来计算发送的内容。

最终，我们需要元信息-有关信息的信息；我们需要标题；我们需要文件具有名称，扩展名和创建日期。我们需要人们过生日，比如说拜托和谢谢你-世界上充满了协议和有关上下文的信息，所以我们不必坐下来一直做所有事情。它占用了一些存储空间，但很容易就值得。



是否真的需要实现各种HTTP方法？


可以说，人们不必实现整个指定的协议，通常对于任何情况都是如此。我不知道英语中的每个单词；我的中国邻居也是一名软件开发人员，但是在不同的行业，对于我在该行业中使用的某些术语，他甚至都不了解中文，更不用说英语了。不过，好事是，我们俩都可以拿起有关HTTP实现的文档，他可以编写服务器，而我可以编写客户端，并且可以在不同的体系结构上使用不同的编程语言，并且它们仍然有效，因为它们遵循协议

很可能您的用户都不会发出除GET请求之外的任何东西，不会使用持久性连接，将JSON以外的任何内容作为主体发送，或者需要接受除text / plain，因此您可以编写一个真正精简的Web服务器，该服务器只能满足客户端浏览器非常有限的需求。但是您不能随意决定取消使“某些文本通过套接字”成为HTTP的基本规则。您不能放弃以下基本概念：请求将是一个字符串，例如：如果您更改了其中的任何内容-不再是HTTP-则是其他内容，并且只能与旨在理解它的内容一起使用。 HTTP是这些定义的含义，因此，如果要实现HTTP，则必须遵循这些定义。


Update

您的问题已经有所发展，这是对您提出的要求的回应：


为什么HTTP协议具有方法概念？从历史上看，您需要认识到事情在设计和实现上更加僵化，甚至不存在脚本的程度，甚至认为页面可以是动态的，都是在内存中动态生成并向下推套接字客户端请求并读取并向下推送套接字的磁盘上的静态文件的状态不存在。这样一来，早期的网络就集中在包含链接到其他页面的静态页面的概念上，所有页面都存在于磁盘上，而导航本来应该是由终端大部分对URL上的GET请求进行请求的，服务器将能够进行映射网址到磁盘上的文件并发送。还有一种观点认为，相互链接并链接到其他地方的文档网络应该是一个不断发展的，可演化的事物，因此存在一套方法是有意义的，以便允许具有适当资格的允许用户更新网络而不必可以访问服务器文件系统-提示使用PUT和DELETE之类的用例，其他方法（如HEAD）仅返回有关文档的元信息，以便客户端可以决定是否再次获取它（请记住，我们正在谈论拨号调制解调器时代的来临，这确实是一种原始的慢速技术。获取一个半兆字节的文件的meta并看到它没有更改，并从缓存中缓存本地副本，而不是再次下载，这可能是一个很大的节省

这为方法提供了一些历史背景-以前，URL是不灵活的位，并简单地引用磁盘上的页面，因此该方法很有用，因为它允许客户端描述文件的意图。服务器将以各种方式处理该方法。在超文本的原始视觉中，实际上并没有URL是虚拟的或用于切换或映射的URL（实际上仅是Text）web

我不希望这个答案成为具有日期的历史记录的文档，并引用确切何时开始发生变化的参考文献（为此您可以阅读Wikipedia），但是随着时间的流逝，可以说足以了。 Web的发展势头越来越大，在服务器-客户端连接的每一端，我们正在扩展创造丰富的多媒体体验的机会。浏览器支持种类繁多的用于格式化内容的标签，每个浏览器都在竞相实现必需的媒体丰富功能以及使事物看起来令人眼花new乱的新方法。

脚本到达客户端，插件和浏览器扩展，所有这些都旨在使浏览器成为功能强大的一切。在服务器端，基于算法或数据库数据的内容主动生成是最大的推动力，并且它继续发展到磁盘上几乎没有文件的程度-当然，我们将图片或脚本文件保留为文件Web服务器并具有浏览器GET，但是越来越多的浏览器显示的图片和运行的脚本不是您可以在文件资源管理器中打开的文件，它们是生成的内容，是按需完成的一些编译过程的输出，描述如何绘制像素而不是像素的位图数组的SVG或从诸如TypeScript

的更高级形式的脚本中发出的JavaScript


现在是磁盘上的固定内容；将数据库数据格式化并整形为HTML，供浏览器使用，并由服务器完成，以响应url以某种方式引用了多个不同的编程例程。

我在对问题的评论中提到，这有点像一个完整的圈子。过去，当计算机花费成千上万个房间时，通常允许多个用户通过数百个笨拙的终端使用一个超级强大的中央大型机-键盘和鼠标，绿屏，发送一些文本，获取一些信息。发短信。随着时间的推移，随着计算能力的提高和价格的下降，人们开始使用台式计算机，而台式计算机的功能要比早期大型机强大，并且可以在本地运行强大的应用程序，因此大型机模型已经过时了。但是它从未消失，因为事情发展了另一种方式，并在某种程度上恢复为提供大多数有用应用程序功能的中央服务器，以及数百台客户端计算机，它们除了在屏幕上绘图外，几乎不做其他任何事情，然后将数据提交并接收/从服务器。在这段过渡时期内，您的计算机足够聪明，可以同时运行自己的单词和Outlook副本，这又一次让位给了在线办公，您的浏览器是一种用于在屏幕上绘制图片并编辑文档/电子邮件的设备。重新编写为驻留在服务器上的东西，然后将其保存在服务器上，发送给其他用户并与其他用户共享，这是因为浏览器只是一个外壳，可在任何时间提供此东西在其他地方的部分视图


从答案中，我对为什么有方法的概念有了一定的了解。这引出了另一个相关的问题：

例如gmail compose链接中的PUT / POST请求和数据将被发送。浏览器如何知道要使用哪种方法？


默认情况下，它使用GET，这是约定/规范，因为这是键入URL并按return时将发生的命令


是否服务器发送的gmail页面包含调用gmail compose请求时要使用的方法名称？


这是我在上面的评论中提到的关键内容之一。在现代网络中，页面甚至都不再相关。一旦页面成为磁盘上的文件，浏览器便会获取。然后，它们成为主要通过将数据放入模板中而动态生成的页面。但是它仍然涉及“从服务器请求新页面，获取页面，显示页面”的过程。页面交换真的很流畅；您没有看到它们加载，调整大小和颠簸它们的布局，因此看上去更平滑，但仍然是浏览器用另一个页面替换整个页面或页面的一部分

现代的做事方式是使用单页应用程序。浏览器在内存中有一个文档，该文档以某种方式显示，对服务器进行脚本调用并获取一些信息，然后操纵该文档，以便页面的一部分以可视方式更改以显示新信息-整个过程运行浏览器不会加载另一个新页面；它只是成为一个UI，其中部分内容的更新就像一个典型的客户端应用程序（如word或Outlook）一样。新元素出现在其他元素之上，并且可以在模拟对话框窗口等周围拖动。所有这些都是浏览器脚本引擎使用开发人员想要的任何http方法发送请求，取回数据并查看浏览器正在绘制的文档。您可以认为现代浏览器是一种出色的设备，类似于整个操作系统或虚拟计算机。一种可编程设备，具有相当标准化的方式来在屏幕上绘制事物，播放声音，捕获用户输入并将其发送进行处理。使它绘制UI所需要做的就是为它提供一些html / css，使它成为UI，然后不断调整html以使浏览器更改其绘制的内容。哎呀，人们习惯于看到地址栏的更改/将其用作意图的方向，即使未完成导航（请求整个新页面），单个页面的应用程序也会以编程方式更改url


当我们调用www.gmail.com时，它必须使用GET方法，浏览器如何知道要使用此方法？


它确实是GET。因为它是指定的。第一个请求是历史上一直以来的请求-获取一些初始html来绘制UI，然后永久性地对其进行拨动和操作，或者使用其他脚本来获得另一个页面，该其他脚本可以进行操作和响应式UI并进行响应。 br />
就像一些答案说的那样，我们可以在DELETE方法上创建新用户，这引起了对HTTP协议中方法概念背后的意图的质疑，因为归根结底，这完全取决于服务器他们要将URL映射到什么功能。 。客户端为什么要告诉服务器用于URL的方法。


历史。遗产。从理论上讲，我们明天可以扔掉所有的http方法-我们处于编程成熟度级别，在这里，方法已经过时了，因为URL是可处理的，在某种程度上它们可以作为向服务器指示要保存数据的切换机制。正文作为草稿电子邮件，或删除草稿-服务器上没有/ emails / draft / save / 1234文件-对该服务器进行了编程，可以将网址分开，并知道如何处理正文数据-保存它作为id为1234的电子邮件草稿，因此肯定有可能取消方法，除了围绕它们长大的传统兼容性外。最好仅将它们用于所需的内容，而在很大程度上忽略它们，而使用所需的任何东西使它们正常工作。我们仍然需要指定的方法，因为您必须记住，它们对于我们创建应用程序的浏览器和服务器具有重要意义。客户端脚本想要使用基础浏览器发送数据，它需要使用一种方法来使浏览器按其要求进行操作-可能是POST，因为GET将其所有变量信息打包到url中，并且具有长度限制在很多服务器上。客户端希望服务器提供长响应-不要使用HEAD，因为根本不应该具有响应主体。也许您选择的浏览器和服务器没有任何限制，但是也许有一天，他们将在另一端分别遇到另一种实现方式-出于互操作的精神，坚持规范使其工作更好

#2 楼

可以将HTTP视为远程过程调用的通用原理的一种特定情况：您通过请求中的某个变量字段告诉服务器所需的内容，服务器将做出相应的响应。到目前为止，由于“ Web 2.0”的复杂交互性，这些相同的功能被推送到请求的每个字段中：URL，标头，正文-每个应用程序服务器和应用程序都以自己的方式理解它们。但是，最初的网络更简单，使用的是静态页面，并且人们认为HTTP方法提供了足够的交互性。值得注意的是，HTTP有很多方法，这些方法很少使用（如果有的话），其中的一些方法由于使用了REST才显得光明。例如。在REST之前，PUT和DELETE处于垂死状态，而TRACE和PATCH仍然不可见。得出的结论是，HTTP的RPC模型与后面的应用程序并不完全匹配，并且应用程序仅通过GET和POST实现了自己的模型，但那时还不能扔掉HTTP。

REST注意，如果将PUT和DELETE带回来，HTTP方法可以满足大多数应用程序的典型CRUD用例的要求，则与您的建议完全相反。分配给它们的文件会受到浏览器和中间件（如代理服务器）的尊重：POST，PUT，DELETE和PATCH请求可能会产生副作用，并且可能不是幂等的，因此客户端应用程序和中间件应谨慎操作，不要在没有明确表示的情况下触发这些请求用户的操作。实际上，设计不良的Web应用程序确实使用GET进行了不安全的操作，例如Google Web Accelerator预取器通过删除此类站点上的数据而造成麻烦，因此其Beta版在启动后不久就被暂停。

因此，要回答“我们可以”这个问题：当然，您只需要在一个协议上达成共识，该协议将告诉服务器应用您要执行的操作，然后将参数放在URL /正文中的某个位置，例如动作的目标项目。这组操作仅受特定应用程序限制，因此您需要可扩展的协议。但是，您需要让客户端应用知道哪些请求是安全的，并且可能需要考虑其他细微差别，例如缓存控制。

#3 楼

从我个人作为开发人员的角度来看，它可以使创建API端点变得更加容易。例如，如果我写了一个控制器来管理网站上的产品，那么我可以使用相同的URL来执行多种不同的操作。

示例：

GET https://example.com/api/products/1234

这将获取产品1234的详细信息。

POST https://example.com/api/products/1234

这将使用请求正文中的数据创建ID为1234的产品。

PUT https://example.com/api/products/1234

这将使用请求正文中的数据更新产品1234。

DELETE https://example.com/api/products/1234

这将删除ID为1234的产品。


我可以为每个操作设置不同的端点，但这会使过程复杂化，并使其他开发人员难以理解。

#4 楼

HTTP协议中的诸如GET和POST之类的方法有什么需求？


似乎您忘记了HTTP服务器仅用于服务文件的旧时代。不运行脚本，CGI或生成此类动态内容。

请求方法是关于如何处理这些文件的基本标准化动词集...


GET表示下载

HEAD表示获取以下信息

PUT表示上传

DELETE表示删除

POST表示将数据发送到

选项表示我可以做什么


在HTTP / 0.9的那天，请求行是请求分支中唯一的内容协议的;没有请求标头，没有响应标头。您只需键入GET /somefile，然后按Enter键，服务器将返回响应正文（即HTML内容），好的，再见（即关闭连接）。

如果您只是想问一下为什么这样设计的？我的回答是因为它最初是为处理当时存在的那种内容交换而编写的，即应用户请求提供静态HTML文件。

但是，如果您想问一下如何对待这些内容交换的话现代应用程序服务器中的语义...


我们不能仅使用请求正文和响应正文来实现HTTP协议吗？


<


是否真的需要实现各种HTTP方法？


我的回答是：做任何您想做的事，但请记住，您应该不能以违反协议期望的方式实现应用程序逻辑：像GET这样的期望不应更改数据（或非常宽松，至少具有幂等结果），HEAD应该具有与GET相同的结果，但没有响应主体，PUT应该使可用目标URI的内容（如果成功）。

如果您在没有仔细考虑其含义的情况下违背了期望，那么各种令人不快的事情将会Appen，就像...


当您将shoehorn GET方法用于数据提交时，服务器可能会吐出414“ URI Too Long”错误。
当您将shoehorn GET方法用于数据修改时，您会发现有时修改无法通过当用户位于缓存代理后面时，或者当用户从书签中调用URL时（或Web爬网程序到达该URL时），可能会进行意外修改。工具（例如wget --spider）在您的网站上无法使用。
当您在内容下载中使用POST方法时，您会发现添加书签或什至在浏览器中输入URL都不起作用。 。


“初学者知道规则，而退伍军人知道例外。”

无论如何，您可能最终会找到一些有效的借口来违反某些规则一些狭窄的用例；但请务必进行研究并考虑所有可能性。否则，您最终将失去互操作性，并破坏“用户体验”。

无法保证用户始终使用您测试过的主流名牌客户/用户代理的最新发布。他们可以使用根据自己的需求量身定制的本地品牌（包括我在内），从隔壁的专卖店订购的定制品牌，或者从储藏室中挖出来的老式品牌。即使有所有这些，您的站点仍有望提供合理的服务。这就是我们拥有标准的原因。
粗心地违反标准也意味着您在对用户施加歧视。

#5 楼

从理论上讲，我们可以在所有地方使用get，这确实可以完成工作。某些软件甚至在请求正文中使用GET（我正在查看您的elasticsearch / kibana）。这当然是一件可怕的事情。

最重要的原因是因为不同的方法具有不同的语义。有些是安全的，有些是幂等的。有些都是。看看哪个

这很重要，例如与其他应用程序交互时。 GET端点不应该有副作用。当Google爬到您的身边时，这一点很重要。 PUT应该是幂等的，这意味着如果出现故障，客户端可以自由地重试。 POST并非如此，如果在发布请求上按f5键，为什么浏览器必须在丑陋的确认框上显示。 />

#6 楼

您还可以将GET，POST等视为同一函数的重载，甚至视为getter和setter。

GET_MyVar()不会采用输入参数（也称为请求正文），但返回某些内容。

POST_MyVar(string blah)使用输入（同样是请求主体）执行某些操作，并且可能返回某些内容。 （它也至少需要返回一个响应代码，以便我们知道该函数已运行！！） />是的，我们可以使用以下命令实现所有功能：DELETE_MyVar()

这样，我们可以只接受一个调用，然后根据其他参数选择要执行的操作。

但是一个这种方法的便利之处在于，它允许浏览器和服务器优化这些事物的工作方式。例如，服务器可能希望在MyVar(string Action, string? blah)处阻止所有请求。也许浏览器想要在Action==DELETE处缓存内容。如果不是，则在每个函数中我们都必须编写Action==GET.

并不需要完全按照协议来实现所有内容，但是协议基本上是一组规则所有人都决定效仿。这样，即使我没有看到服务器，我也可以轻松猜出您的网站会做什么！

#7 楼

HTTP方法有不同的用途。通常，GET用于下载，POST用于上传。

仅使用请求正文和响应正文实现HTTP协议的一部分的唯一方法是实现POST。 GET没有请求正文。它仅具有带标头的请求本身，而没有正文。这只是下载文档的请求。 POST同时具有请求正文（文件上传）和响应正文（显示结果的文档）。

那么您能实现POST并完成吗？如果您希望自己的网站在标准浏览器中可用，则不可以。浏览器发送的默认请求类型是GET。通常仅在提交网页中的表单或进行AJAX调用时发送POST请求。仅当此特定服务器仅用于AJAX调用，而不用于用户可见的页面时，您才可以仅使用POST。

浏览器有时还会发送HEAD请求来检查是否该文档自上次下载以来就已更改，因此建议至少也要实施该文档。

无论如何，没有充分的理由为您的站点实现Web服务器从头开始。 HTTP协议很复杂。除了各种方法，您还必须实现流水线和分块的请求。在像Apache，Nginx或IIS这样的为您处理HTTP协议的Web服务器之上构建Web应用程序要容易得多。您提到了Servlet，因此也许应该使用运行Servlet的Tomcat或JBoss Web服务器。

#8 楼

没错，我们可以做到这一点，如果我可以用POST方法取代HTTP，而其他方法则不能取代HTTP，那么GET，POST，PUT等只是历史惯例，尽管我不得不承认消除GET的工作量很大，那不可能完成，那匹马已经拴在那匹马上了

#9 楼

您提议的协议对黑客的安全性将大大降低。

网站离开存储有关变量等信息的URL的原因很简单，原因很简单：它为攻击者提供了一个非常重要的选择。攻击系统的简单方法。通过观察纯文本URL信息，他们可以确定构造为发送到Web服务器的数据的方式。然后，他们可以使用此信息通过使用特殊构造的URL对您的服务器执行攻击，该URL允许他们将恶意代码或数据注入您的服务器。