post 相比get 有很多优点，为什么现在的HTTP通信中大多数请求还是使用get？

好吧， 除了哲学方式的回答以外，下面是一个浏览器从业人员的看法

事实上GET 和 POST 在实践上面有非常大的区别，这两种方法在语义上面并非能互相取代。

POST 是否比 GET 安全

是的， POST要比GET安全一点点，注意，是一点点。。。

说这两者都是明文传送当然是没有错的了，但是这里有一个细节，就是GET的URL会被放在浏览器历史和WEB 服务器日志里面。

POST 发完基本就木有了。。

所以如果你把关键数据放在GET里面，被人偷窥了浏览器，或者WEB服务器被入侵日志被人倒去了，基本泄露可能性100%。而POST来说，日志没有记录，只要数据库服务器不被入侵，基本还是安全的。

当然如果被抓了包，这一切都没有什么卵用，所以，HTTPS该用还是得用。


GET 相对 POST 的优势是什么

最大的优势是， GET 的URL可以人肉手输啊。。。你在地址栏打个POST给我看看。本质上面， GET 的所有信息都在URL， 所以很方便的记录下来重复使用。

所以如果你希望
－ 请求中的URL可以被手动输入
－ 请求中的URL可以被存在书签里，或者历史里，或者快速拨号里面，或者分享给别人。
－ 请求中的URL是可以被搜索引擎收录的。
－ 带云压缩的浏览器，比如Opera mini/Turbo 2, 只有GET才能在服务器端被预取的。
－ 请求中的URL可以被缓存。

请使用GET. 

大家有没有注意到，其实这里面很多方面的要求是和网站的运营相关的，而不是技术相关的。任何的技术行为中，其实多多少少都能看到商业的影子。

反之，就用POST. 特别是有一些东西你是不想让人家可以在浏览器地址栏里面可以输入的。比如，如果你设计一个blog系统, 设计这样一个URL来删掉所有帖子。

http://myblog.com/?action=delete_all


我只能说很快你就知道什么叫不作死就不会死这个道理了，搜索引擎的爬虫分分钟教你做人。

另外一个准则是，可以重复的交互，比如取个数据，跳个页面， 用GET.
不可以重复的操作， 比如创建一个条目/修改一条记录， 用POST, 因为POST不能被缓存，所以浏览器不会多次提交。

WEB API 的设计相对于网页来说更加复杂，同时也有GET/POST的问题，目前主流接受的方法是RESTful, 参见这里

Representational state transfer

这个是趋势：


同时对于何时用GET, W3C 也有一篇文章专门解释：


摘一点出来：

1.3 Quick Checklist for Choosing HTTP GET or POST

  • Use GET if:
    • The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).

and

  • Use POST if:
    • The interaction is more like an order, or
    • The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or o The user be held accountable for the results of the interaction.

However, before the final decision to use HTTP GET or POST, please also consider considerations for sensitive data and practical considerations.

 

 

************************************************************************************************************************************

因为它们表达的语义不一样，这决定了主干网络可以对其做不同的处理。

get表达的是一种幂等的，只读的，纯粹的操作，即它除了返回结果不应该会产生其它副作用（如写数据库），因此绝大部分get请求（通常超过90%）都直接被CDN缓存了，这能大大减少web服务器的负担。 而post所表达的语义是非幂等的，有副作用的操作，所以必须交由web服务器处理。

把所有get请求换成post，意味着主干网络上的所有CDN都废掉了，web服务器要处理的请求数量将成百上千倍地增加，显然这不是一个聪明的做法！

 

-------------------------绕圈子的分割线-----------------------

 

我觉得对于一个真诚地讨论问题的人来说，以上解释就足够了，然而有些人非要把圈子绕大，那我就陪你们把圈子绕完咯 “get和post就是那几个字母的区别” 开发过web服务器的同学都知道，只要请求打到了服务器上，那么要怎么解释这个请求的内容就完全是服务器自己的事情了，只是web服务器开发框架通常会自动帮你做一些解析http请求的事情而已。 所以如果说客户端和服务端都是自己写，那当然很随意，想怎么玩就怎么玩好了，事实上在没有RESTful建议的时候，大家也的确玩得很随意。

然而说出“就是几个字母的区别”这种话仅仅是表达了“我搞过服务端开发”这层意思而已。 实际上问题真正困难的地方在于，网络上每天产生的请求数目庞大，并且其中绝大部分请求均为只读请求，如果所有这些请求都要交由web服务器直接处理，这无疑是巨大的资源浪费。所以大家自然能想到，假如我们能在请求到达web服务器之前，就对请求作一个初步的解析，得知请求的大致意图，对于不同意图的请求以不同方式满足（比如请求经过nginx的时候nginx就会解析请求头信息，然后根据这些信息把请求分配给合适的角色去进一步处理），那么事情就合理多了。 于是RESTful的建议就在这个时候应运而生了，它的出现正是为了解决http基础设施未能得到充分合理利用的问题。

所以我们开发一个服务的时候，选择http协议（而不是直接用tcp），最根本的原因是，我们希望它可以直接和浏览器打交道，可以借用现有的http基础设施，它的行为能被除自己的客户端以外的，网络中的其它角色所理解。 （而不是仅仅靠http解决文本编码问题 这才是我们之所以强调get和post区别，强调“语义”的真正原因。

 

references:

http://www.zhihu.com/question/31640769

posted @ 2015-07-01 09:31  foo__hack  阅读(2218)  评论(0)  编辑  收藏  举报