好的，我知道目的不同。 GET 是获取一些数据。发出请求并取回数据。 POST 应该用于 CRUD 操作，而不是我相信的 read。但归根结底，服务器是否真的在乎它最终收到的是 GET 还是 POST？
【问题讨论】：
根据 HTTP RFC，GET 不应该有任何副作用，而 POST 可能有副作用。
最基本的例子是 GET 不适用于购买交易或将文章发布到博客等任何事情，而 POST 适用于具有后果的操作。
根据 RFC，您可以让用户对 POST 完成的操作（例如购买）负责，但不对 GET 操作负责。 '因为这个原因，机器人总是使用 GET。
9.1.1 安全方法
实施者应该意识到 软件代表用户
他们在互联网上的互动， 并应小心允许 用户了解他们的任何操作 可能会有一个
对自己意想不到的意义 或其他人。特别是，该公约有 已确定 GET 和
HEAD 方法不应该有 采取行动的意义
除了检索。这些方法 应该被认为是“安全的”。这个 允许用户代理代表其他 方法，例如 POST、PUT 和 DELETE，以一种特殊的方式，使 用户被告知以下事实 正在执行一个可能不安全的操作 请求。当然不可能 确保服务器不
产生副作用 执行 GET 请求；实际上， 一些动态资源认为 特征。重要的区别 这是用户没有请求 副作用，因此 不能对他们负责。
【讨论】：
如果搜索引擎正在抓取页面，它会这样做，因为它们会发出 GET 请求而不是 POST。假设您的页面上有一个链接：
http://www.example.com/items.aspx?id=5&mode=delete
如果在删除之前没有执行某种授权检查，Googlebot 可能会从您的页面come in and delete items。
【讨论】：
既然你是编写服务器软件的人（大概），那么它会在乎你是否告诉它关心。如果您以相同的方式处理 POST 和 GET 数据，那么不，它不会。
但是，浏览器肯定在乎。例如，刷新或单击返回作为 POST 响应的页面会弹出“您确定要再次提交数据”提示。
【讨论】：
GET 有基于发送浏览器的数据限制限制：
URL 长度规范没有规定最小或最大 URL 长度，但实施因浏览器而异。在 Windows 上：Opera 支持 ~4050 个字符，IE 4.0+ 正好支持 2083 个字符，Netscape 3 -> 4.78 在导致关闭错误之前支持多达 8192 个字符，而 Netscape 6 在导致启动错误之前支持 ~2000 个字符
【讨论】：
如果您使用 GET 请求来更改后端状态，如果某种网络爬虫遍历您的网站，您将面临发生坏事的风险。当初 wiki 刚开始流行的时候，因为“删除页面”功能是作为 GET 请求实现的，所以有整个网站被删除的恐怖故事，当 Googlebot 来敲门时，结果是灾难性的......
【讨论】：
“在以下情况下使用 GET：交互更像是一个问题（即，它是一种安全操作，例如查询、读取操作或查找）。”
“在以下情况下使用 POST：交互更像是一个订单，或者交互以用户可以感知的方式更改资源的状态（例如，订阅服务），或者用户需要为交互的结果。”
【讨论】：
您会注意到一些细微的安全差异。查看我的问题
需要记住的重要一点是，GET 将进入浏览器历史记录，并将通过代理以纯文本形式传输，因此您不需要任何敏感信息，例如 GET 中的密码。
也许很明显，但值得一提。
【讨论】：
根据 HTTP 规范，GET 是安全且幂等的，而 POST 两者都不是。这意味着一个 GET 请求可以重复多次而不会产生副作用。
即使您的服务器不关心（这不太可能），您的客户端和服务器之间也可能存在中间代理，他们都有这种期望。例如，在您的 ISP 或其他提供商处缓存数据以提高性能的代理。对于加速器也是如此，例如，您的浏览器的预取插件。
因此可以缓存 GET 请求（基于某些参数），如果失败，可以自动重复，不会产生任何有害影响。所以，你的服务器真的应该努力履行这个合同。
另一方面，POST 不安全，也不是幂等的，并且每个代理都知道不缓存 POST 请求的结果，或者自动重试 POST 请求。因此，例如，信用卡交易永远不会是 GET 请求（您不希望帐户因为网络错误等而被多次扣款）。
这是一个非常基本的看法。有关更多信息，您可以考虑 Ruby 和 Richardson 的“RESTful Web Services”一书（O'Reilly 出版社）。
要快速了解 REST 主题，请参阅这篇文章：
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
有趣的是，大多数人都在争论 PUT v POST 的优点。 GET v POST 问题一直以来都得到了很好的解决。忽略它，后果自负。
【讨论】：
GET 在浏览器端有限制。例如，some browsers 限制 GET 请求的长度。
【讨论】：
我认为一个更合适的答案是，你几乎可以对两者做同样的事情。然而，与其说是偏好问题，不如说是正确使用的问题。我建议您使用 GET 和 POST 来打算如何使用它们。
【讨论】：
用户应该能够为结果页面添加书签吗？要考虑的另一件事是某些浏览器/服务器错误地限制了 GET URI 长度。
编辑： 更正了字符长度限制说明 - 感谢 ars！
【讨论】：
这取决于服务器端的软件。一些库，比如 perl 中的 CGI.pm 默认处理这两种情况。但是在某些情况下，您或多或少必须使用 POST 而不是 GET，至少用于将数据推送到服务器。大量数据（相应的 GET url 会变得太长）、二进制数据（以避免大量编码/解码麻烦）、多部分文件、未解析的标头（用于持续更新 AJAX 之前的样式...）和类似的.
【讨论】：
从技术上讲，服务器不能以一种或另一种方式关心它接收到的请求类型。它会盲目地执行任何通过网络发出的请求。
这是问题所在。如果您的操作破坏或修改了 GET 操作中的数据，Google 将在您的网站通过索引抓取时将其撕毁。
【讨论】：
服务器通常不在乎。但正如你所提到的，这主要是为了遵循良好的做法。客户端也很重要 - 如前所述，您通常不能为 POST 页面添加书签，并且某些浏览器对非常长的 GET 查询的 URL 长度有限制。
【讨论】：
由于 GET 旨在指定您想要获取的资源，根据服务器端的确切软件，Web 服务器（或它前面的负载平衡器）可能对 GET 请求有大小限制，以防止拒绝服务攻击...
【讨论】：
请注意，浏览器可能会缓存 GET 请求，但通常不会缓存 POST 请求。
【讨论】：
是的，这很重要。 GET 和 POST 完全不同，真的。
通常情况下，您是对的，GET 用于从服务器“获取”数据并显示页面，而 POST 用于将数据“发布”回服务器。在内部，无论是 GET 还是 POST，您的脚本都会获得相同的数据，所以不，服务器并不真正关心。
主要区别在于 GET 参数是在 URL 中指定的，而 POST 不是。这就是为什么 POST 用于注册和登录表单的原因——您不希望在 URL 中输入密码。同样，如果您正在查看不同的页面或显示某些数据的特定视图，您通常需要一个唯一的 URL。
【讨论】：
从技术上讲，没有。 GET 所做的只是在 HTTP 请求的第一行发布内容，然后 POST 在正文中发布内容。
但是，“网络基础设施”如何处理这些差异会产生巨大的差异。我们可以为此写一整本书。但是，我会给你一些“最佳实践”：
当您的 HTTP 请求会更改 Web 服务器内的“具体”内容时，请使用“POST”。即，您正在编辑页面、制作新记录等。 POST 不太可能被缓存，或者被视为“可重复且无副作用”的内容
当您想“查看对象”时，请使用“GET”。现在，这样的外观可能会在缓存或记录保存方面改变“幕后”的一些东西，但它不应该改变任何“实质性”的东西。即，我可以一遍又一遍地重复我的 GET 并且不会发生任何不好的事情，除了夸大的命中数。 GET 应该可以轻松添加书签，以便用户稍后可以返回到同一个对象。
GET 的参数（传统上 ? 后面的东西）应该被认为是“视图的属性”或“要查看的内容”等等。同样，它实际上不应该改变任何东西：为此使用 POST。
最后，当您发布某些内容（例如，您正在创建新评论）时，让发布处理发出 302 以将用户“重定向”到查看该对象的新 URL。即，POST 处理信息，然后将浏览器重定向到 GET 语句以查看新状态。作为 POST 的结果显示信息也可能导致问题。经常使用重定向，可以让事情变得更好。
【讨论】：
这确实很重要。我收集了大约 11 件你应该知道的事情。
【讨论】：
不，除了@jbruce2112 回答和上传文件需要 POST 之外，他们不应该这样做。
【讨论】：