为什么我们需要 HTTP GET？有什么不能通过 HTTP POST 实现的吗？答案

【问题标题】：Why do we need HTTP GET? Is there anything that can't be achieved by HTTP POST?为什么我们需要 HTTP GET？有什么不能通过 HTTP POST 实现的吗？
【发布时间】：2011-04-27 14:23:58
【问题描述】：

据我所知，GET 能做什么，POST 也能做到。那么为什么在定义 HTTP 协议时首先需要 GET。如果 GET 只是为了获取资源，人们仍然可以通过在 URL 中发送参数值来更新资源。为什么会有这个漏洞？还是在服务器端进行编码以更新 GET 请求资源的人编写了错误的代码？

【问题讨论】：

聪明、最短、切中要害。可爱的评论。
为什么投反对票？至少从下面的答案来看，这似乎是一个相当合理的问题。
@Tenner，我同意。放松人们！虽然我对最后一句话有点困惑...... Bozo又是谁？
@Abe 感谢您指出这一点。删除了 bozo 词。现在问题看起来更好更客观了。

标签： http post get

【解决方案1】：

每当您进行网络搜索并希望将某人链接到它时，您都可以通过以下方式轻松完成：

http://www.google.com/search?q=lol

您能想象告诉某人改为执行 POST 请求吗？一个 POST 请求并不能真正像那样添加书签，这就是 GET 有用的原因。

正如其他答案所述，它们只是有不同的目的。 GET 用于获取，POST 用于发布。

【讨论】：

但我不认为书签是定义 GET 时的目的。是的，这是一个好处。但是我们真的需要单独为书签定义一个新的 HTTP 方法吗？
浏览器供应商也可以为 POST 请求实现书签。

【解决方案2】：

实际上，没有浏览器通过点击链接来实现 POST（不拦截 JavaScript 中的点击事件），也没有为 POST 数据添加书签。此外，语义上 POST 和 GET 服务于不同的目的。一种用于向应用程序发布数据，另一种用于从应用程序获取数据。这些语义具有实际意义，但它们也具有与应用程序设计质量相关的理论设计意义：处理 GET 与 POST 不同的应用程序可能存在大量安全问题和工作流错误。

【讨论】：

感谢无眼睑。很棒的评论。但是，我看到许多 servlet 以相同的方式处理 get 和 post。那是糟糕的编码吗？
@Sanjeev，它本质上并不坏，但它是一个线索，表明可能有问题。一个设计良好的应用程序通常会比 GET 查询更严格地检查 POST 数据； GET 请求应清理数据库访问和重新显示的输入，并拒绝用户权限之外的请求； POST 请求也应该做这些事情，但可能会应用更广泛的权限，并且可能会在存储之前对输入执行其他验证和清理。通过在语义上区别对待 GET 和 POST，开发人员可以更明确地控制其应用程序的安全性和稳定性。

【解决方案3】：

假设我想通过链接将变量发送到页面，我可以使用 POST 执行此操作吗？不，但是使用 GET，我可以通过 ?variableName=someValue 发送一些东西

【讨论】：

通过 POST 正文发送变量有什么危害？
我的意思是，您不能使用简单的<a href="url.com/?value=this">Link</a>通过 POST 发送特定值
你的意思是说我必须在 POST 中使用表单和提交按钮。发送参数时 GET 分数优于 POST 的简单性。同意。但我提出问题的动机不同。
嗯，您是在暗示 GET 的创建者在他们的设计中存在缺陷。我认为恰恰相反；他们看到了允许通过 URL 发送 GET 数据的机会和有用性。

【解决方案4】：

一切都可以使用原始 TCP 连接来实现。然而，我们经常使用 HTTP 而不是原始 TCP 连接，因为 HTTP 提供了一个抽象层，因此提供了便利和符合要求的实现。同样，我们正确使用 HTTP（GET、POST、PUT、DELETE 等）而不是笨拙地使用 HTTP（仅限 POST），因为这些动词提供了额外的抽象层，因此提供了便利和符合要求的实现。

【讨论】：

【解决方案5】：

HTTP specified different methods for different purposes. GET method 旨在用于“检索由 Request-URI 标识的任何信息（以实体的形式）”。特别是，它旨在成为safe and idempotent method。这意味着 GET 请求不应有副作用（即更改数据）：

特别是，已经建立了约定，即 GET 和 HEAD 方法不应具有采取除检索之外的操作的意义。

多次发送相同的请求与只发送一次的结果相同：

方法还可以具有“幂等性”，因为（除了错误或过期问题）N > 0 个相同请求的副作用与单个请求相同。 GET、HEAD、PUT 和 DELETE 方法共享此属性。

【讨论】：

“特别是，它旨在成为一种安全且幂等的方法。”如果我写 - “这是一种安全且幂等的方法”怎么办？ “意图”不是模棱两可吗？它定义了一个规则，但说它不再是一个规则。
@Sanjeev，由于 GET，GET 并不安全和幂等。它是安全的，因为它是安全的和幂等的。这不是规则，而是语义目的。除了良好的编程之外，没有什么可以阻止开发人员开发破坏和覆盖 GET 请求数据的应用程序。

【解决方案6】：

来自RFC 2616：

9.3 获取

GET 方法意味着检索任何内容信息（以实体的形式）由 Request-URI 标识。如果 Request-URI 指的是一个数据产生过程，它是生成的应返回的数据作为响应中的实体，而不是过程的源文本，除非该文本恰好是过程。

GET 方法的语义变化如果请求，则为“条件 GET” 消息包括一个 If-Modified-Since， If-Unmodified-Since, If-Match, If-None-Match 或 If-Range 标头场地。有条件的 GET 方法请求实体仅根据以下转移所描述的情况条件头字段。这有条件的 GET 方法旨在减少不必要的网络使用允许缓存实体无需多次刷新已经请求或传输数据由客户持有。

GET 方法的语义变化如果请求，则为“部分 GET” 消息包含 Range 标头字段。部分 GET 请求仅部分被转让的实体，如在第 14.35 节中描述。这部分 GET 方法旨在减少不必要的网络使用允许部分检索的实体无需转移即可完成客户已经持有的数据。

对 GET 请求的响应是当且仅当满足 HTTP缓存的要求在第 13 节中描述。

请参阅第 15.1.3 节以了解安全性用于表单时的注意事项。

9.5 发布

POST方法用于请求源服务器接受请求中包含的实体作为资源的新下属由 Request-URI 标识请求行。 POST 旨在允许一个统一的方法来覆盖以下功能：
  - Annotation of existing resources;
  - Posting a message to a bulletin board, newsgroup, mailing
列表，或类似的一组物品； - 提供数据块，例如提交结果表格，数据处理过程； - 通过追加操作扩展数据库。实际上 POST 方法执行的功能由服务器确定并且是通常依赖于 Request-URI。发布的实体从属于该 URI 以与文件相同的方式从属于目录包含它，一篇新闻文章是隶属于它所属的新闻组已过帐，或记录是从属的到数据库。

POST 执行的操作方法可能不会产生资源可以通过 URI 标识。在在这种情况下，200（OK）或 204（No 内容）是适当的回应状态，看有没有响应包括一个实体描述结果。

如果已在源服务器，响应应该是 201（已创建）并包含一个实体它描述了状态请求并引用新的资源和 Location 标头（请参阅第 14.30 节）。

对这个方法的反应不是可缓存，除非响应包括适当的缓存控制或使标头字段过期。然而可以使用 303（参见其他）响应指示用户代理检索可缓存资源。

POST 请求必须服从消息规定的传输要求第 8.2 节。

请参阅第 15.1.3 节以了解安全性考虑。

如上所述，如果请求消息具有基于某些标准的条件，则响应可能会随 GET 更改。 POST 要求服务器无论如何都要接受请求。

【讨论】：

【解决方案7】：

你是对的，一切都可以通过 HTTP POST 进行隧道传输。事实上，SOAP Web 服务正是这样做的。一切都是使用 SOAP Web 服务的 POST。

在这种情况下，您是通过 HTTP 进行隧道传输，而不是充分利用 HTTP。如果这就是你想要做的，那很好。

但是，如果您希望利用 HTTP 来获得它提供的简单消息传输之外的功能和好处，那么您应该阅读 RFC 并了解 HTTP 协议的其余部分，包括 GET、PUT、POST、DELETE 和所有标头、缓存管理和结果代码。

【讨论】：