Question

好的，我知道目的不同。 GET是获取一些数据。提出请求并获取数据。 POST应该用于CRUD操作，而不是我认为的读取。但是当它归结为它时，服务器是否真的关心它最终是否接收到GET与POST？

Answer 1

根据HTTP RFC，GET不应该有任何副作用，而POST可能有副作用。

最基本的例子是，GET不适用于购买交易或将文章发布到博客等任何内容，而POST适用于具有后果的操作。

通过RFC，您可以让用户负责POST（例如购买）所做的操作，但不能用于GET操作。 '因此，机器人总是使用GET。

9.1.1安全方法

执行者应该意识到这一点   软件代表用户   他们在互联网上的互动，   并且应该小心允许   用户要了解他们的任何行动   可能需要哪个可能有   对自己意外的意义   或其他人。

特别是，大会有   已经建立了GET和   HEAD方法应该没有   采取行动的重要性   除了检索。这些方法   应该被认为是“安全的”。这个   允许用户代理代表其他代理   方法，如POST，PUT和   以特殊方式删除，以便   用户意识到这一事实   可能不安全的行动正在发生   请求。

当然，这是不可能的   确保服务器没有   产生副作用的结果   执行GET请求;事实上，   一些动态资源考虑到了   特征。重要的区别   这是用户没有请求   副作用，因此   不能对他们负责。

Answer 2

如果搜索引擎正在抓取页面，那么它会发出GET请求而不是POST。假设您的页面上有链接：

http://www.example.com/items.aspx?id=5&mode=delete

如果在删除之前未执行某种授权检查，Googlebot可能会从您的网页come in and delete items开始。

Answer 3

既然您是编写服务器软件的人（大概是），那么它会关心您是否关心它。如果你以相同的方式处理POST和GET数据，那么不，它没有。

然而，浏览器绝对关心。例如，刷新或单击回到您作为对POST的响应而获得的页面会弹出“您确定要再次提交数据”提示。

Answer 4

GET具有基于发送浏览器的数据限制限制：

URL长度的规范并未规定最小或最大URL长度，但实现因浏览器而异。在Windows上：Opera支持~4050个字符，IE 4.0+支持2083个字符，Netscape 3 - ＆gt; 4.78在关闭错误之前支持最多8192个字符，Netscape 6在启动错误之前支持~2000

Answer 5

如果您使用GET请求来更改后端状态，那么如果某种类型的网络抓取工具遍历您的网站，您就会面临发生不良事件的风险。当wiki首次流行时，有一些恐怖故事被删除，因为“删除页面”功能是作为GET请求实现的，当Googlebot敲响时会带来灾难性的结果......

Answer 6

“使用GET if：交互更像是一个问题（即，它是一个安全的操作，如查询，读取操作或查找）。”

“如果以下情况使用POST：交互更像是订单，或者交互以用户会感知的方式更改资源的状态（例如，订阅服务），或者用户要对互动的结果。“

source

Answer 7

根据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诉POST的优点。 GET和POST问题一直很好地解决了。忽略它是你自己的危险。

Answer 8

GET在浏览器方面有局限性。例如，some browsers限制了GET请求的长度。

Answer 9

我认为更合适的答案是，你可以用两者做同样的事情。然而，这不是一个偏好问题，而是正确使用的问题。我建议您使用GET和POST来使用预期。

Answer 10

您要注意一些微妙的安全差异。看我的问题

GET versus POST in terms of security?

基本上要记住的重要事项是GET将进入浏览器历史记录并将通过代理以纯文本形式传输，因此您不需要任何敏感信息，例如GET中的密码。

明显可能，但值得一提。

Answer 11

用户是否应该能够为生成的页面添加书签？另一件需要考虑的事情是某些浏览器/服务器错误地限制了GET URI长度。

修改：更正了字符长度限制备注 - 感谢ars！

Answer 12

由于GET旨在指定您想要的资源，根据服务器端的确切软件，Web服务器（或其前面的负载均衡器）可能对GET请求有大小限制以防止拒绝服务攻击...

Answer 13

这确实很重要。我聚集了大约11种您应该知道的与它们相邻的东西。

11 things you should know about GET vs POST

Answer 14

从技术上讲，没有。所有GET都会在HTTP请求的第一行发布内容，而POST会将内容发布到正文中。

然而，“网络基础设施”如何处理这些差异会让世界变得与众不同。我们可以写一本关于它的书。但是，我会给你一些“最佳实践”：

当您的HTTP请求改变Web服务器内部“具体”的内容时，请使用“POST”。即，您正在编辑页面，创建新记录，等等。 POSTS不太可能被缓存，或被视为“可重复而没有副作用”的东西

当您想要“查看对象”时，请使用“GET”。现在，这样的外观可能会在缓存或记录保存方面改变“幕后”，但它不应该改变任何“实质性”的东西。也就是说，我可以一遍又一遍地重复我的GET，除了夸大的命中数之外，什么都不会发生。 GET应该很容易收藏，因此用户以后可以回到同一个对象。

GET的参数（传统上的？之后的东西）应该被视为“视图属性”或“查看内容”等等。同样，它实际上不应该改变任何东西：使用POST。

最后一句话，当您发布某些内容（例如，您正在创建新评论）时，请对帖子进行处理，以便将用户“重定向”到查看该对象的新URL。即，POST处理信息，然后将浏览器重定向到GET语句以查看新状态。由于POST而显示信息也可能导致问题。经常使用重定向，并使事情更好。

Answer 15

是的，这很重要。 GET和POST真的很不一样。

你是对的，通常，GET用于从服务器“获取”数据并显示页面，而POST用于将数据“发布”回服务器。在内部，您的脚本获取相同的数据，无论是GET还是POST，所以不，服务器并不真正关心。

主要区别在于GET参数在URL中指定，而POST则不在。这就是POST用于注册和登录表单的原因 - 您不希望在URL中使用密码。同样，如果您正在查看不同的页面或显示某些数据的特定视图，通常需要一个唯一的URL。

Answer 16

请注意，浏览器可能会缓存GET请求，但通常不会缓存POST请求。

Answer 17

服务器通常不关心。但正如你所提到的，它主要是为了遵循良好做法。客户端也很重要 - 如前所述，您通常无法为POST页面添加书签，并且某些浏览器对于长时间GET查询的URL长度有限制。

Answer 18

服务器在技术上无论如何都不关心它收到的请求类型。它将盲目地执行任何来自网络的请求。

问题是什么。如果您的某项操作会在GET操作中销毁或修改数据，那么Google会在浏览索引时撕毁您的网站。

Answer 19

这取决于服务器端的软件。有些库，比如perl中的CGI.pm，默认情况下处理这两个库。但是在某些情况下，您或多或少必须使用POST而不是GET，至少是为了将数据推送到服务器。大量数据（相应的GET url会变得太长），二进制数据（避免大量编码/解码问题），多部分文件，非解析标题（用于AJAX之前的连续更新......）和类似

Answer 20

不，他们不应该除了@ jbruce2112的答案和上传文件需要POST。

GET与POST这真的很重要吗？

20 个答案: