IT界知名的程序員曾說:對于那些月薪三萬以下,自稱IT工程師的碼農們,其實我們從來沒有把他們歸為我們IT工程師的隊伍。他們雖然總是以IT工程師自居,但只是他們一廂情愿罷了。
此話一出,不知激起了多少(碼農)程序員的憤怒,卻又無可奈何,于是碼農問程序員。
碼農:你知道get和post請求到底有什么區別?
程序員:你看這篇就知道了。
碼農:你月薪三萬了?
程序員:嗯。
碼農:你是怎么做到的?
程序員:我做夢做到的
這個問題幾乎面試的時候都會問到,是一個老生常談的話題,然而隨著不斷的學習,對于以前的認識有很多誤區,所以還是需要不斷地總結的,學而時習之,不亦說乎。
關于get和post如果你有條件上百度的話,至少有200百萬條結果,每個人都有每個人的思考,當然,這篇也是我的思考,如果有些結論有錯誤,希望能夠噴起來。在批評中不斷改進,與諸君共勉一句話:若批評無意義,則贊美無意義。
1.1 http的特點
服務端響應response也由四個部分組成,分別是:狀態行、消息報頭、空行、響應正文
1.2 請求方法
http請求可以使用多種請求方法。HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法。
HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
1.3 我們耳熟能詳的的區別
http協議最常見的兩種方法GET和POST,這幾點答案其實有幾點并不準確
get和post誤區
針對上面常見的區別,如果面試的時候這么說,肯定是有很大的毛病,剛在學校面試的時候也曾經囫圇吞棗地這樣說過,現在回過頭再想以前的錯誤認知,又有許多新的認識。
2.1 誤區一
“用處:get常用于取回數據,post用于提交數據”
曾聽到過這樣一種說法:get替換post來優化網站性能,雖然這種說法沒錯,也的確get常被用于取回數據,但是post也被一些ui框架使用于取回數據,比如kendo ui中的grid,就是用post來接受數據的。所以結論是get、post用途也是因地制宜。如果你有使用過kendo UI,會發現分頁、過濾、自定義的參數都包含在form data里面。
請求參數
get是querystring(僅支持urlencode編碼),post是放在body(支持多種編碼)
query參數是URL的一部分,而GET、POST等是請求方法的一種,不管是哪種請求方法,都必須有URL,而URL的query是可選的,可有可無。
2.2 誤區二
“請求參數長度限制:get請求長度最多1024kb,post對請求數據沒有限制”
這句話看上去實在沒毛病啊,菜鳥教程也是這樣說的啊。雖然字面意思上沒有錯誤,但是理解一定要正確。我想說的是GET方法提交的url參數數據大小沒有限制,在http協議中沒有對url長度進行限制(不僅僅是querystring的長度),這個限制是特定的瀏覽器及服務器對他的限制
下面就是對各種瀏覽器和服務器的大處理能力做一些說明
所以為了符合所有標準,url的最好不好超過最低標準的2083個字符(2k+35)。當然在做客戶端程序時,url并不展示給用戶,只是個程序調用,這時長度只收web服務器的影響了。對于中文的傳遞,一個漢字最終編碼后的字符長度是9個字符。
最常見的form表單,瀏覽器默認的form表單,默認的content-type是application/x-www-form-urlencoded,提交的數據會按照key value的方式,jquery的ajax默認的也是這種content-type。當然在post方式中添加querystring一定是可以接收的到,但是在get方式中加body參數就不一定能成功接收到了。
2.3 誤區三
“post比get安全性要高”
這里的安全是相對性,并不是真正意義上的安全,通過get提交的數據都將顯示到url上,頁面會被瀏覽器緩存,其他人查看歷史記錄會看到提交的數據,而post不會。另外get提交數據還可能會造成CSRF攻擊。
2.4 誤區四:“GET產生一個TCP數據包;POST產生兩個TCP數據包。”
這一點理解起來還是有一定難度的,實際上,不論哪一種瀏覽器,在發送 POST 的時候都沒有帶 Expect 頭,server 也自然不會發 100 continue。通過抓包發現,盡管會分兩次,body 就是緊隨在 header 后面發送的,根本不存在『等待服務器響應』這一說。
從另一個角度說,TCP 是傳輸層協議。別人問你應用層協議里的 GET 和 POST 有啥區別,你回答說這倆在傳輸層上發送數據的時候不一樣,確定別人不抽你?
參考資料:https://zhuanlan.zhihu.com/p/25028045
3.1 狀態碼1xx
服務器僅接收到部分請求,但是一旦服務器并沒有拒絕該請求,客戶端應該繼續發送其余的請求。
服務器轉換協議:服務器將遵從客戶的請求轉換到另外一種協議。
擴展的狀態碼,代表處理將被繼續執行
3.2 狀態碼2xx:成功
請求成功(其后是對GET和POST請求的應答文檔。)
請求被創建完成,同時新的資源被創建。
供處理的請求已被接受,但是處理未完成。
文檔已經正常地返回,但一些應答頭可能不正確,因為使用的是文檔的拷貝。
沒有新文檔。瀏覽器應該繼續顯示原來的文檔。如果用戶定期地刷新頁面,而Servlet可以確定用戶文檔足夠新,這個狀態代碼是很有用的。
沒有新文檔。但瀏覽器應該重置它所顯示的內容。用來強制瀏覽器清除表單輸入內容。
客戶發送了一個帶有Range頭的GET請求,服務器完成了它。
3.3 狀態碼3xx:重定向
多重選擇。鏈接列表。用戶可以選擇某鏈接到達目的地。最多允許五個地址。
所請求的頁面已經轉移至新的url
所請求的頁面已經臨時轉移至新的url。
所請求的頁面可在別的url下被找到。
未按預期修改文檔。客戶端有緩沖的文檔并發出了一個條件性的請求(一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔)。服務器告訴客戶,原來緩沖的文檔還可以繼續使用。
客戶請求的文檔應該通過Location頭所指明的代理服務器提取。
此代碼被用于前一版本。目前已不再使用,但是代碼依然被保留。
被請求的頁面已經臨時移至新的url。
3.4 狀態碼4xx:客戶端錯誤
3.5 狀態碼5** 服務端錯誤
網頁題目:程序員:我終于知道post和get的區別
URL分享:http://vcdvsql.cn/news20/102520.html
成都網站建設公司_創新互聯,為您提供App設計、建站公司、靜態網站、云服務器、電子商務、自適應網站
廣告
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源:
創新互聯