get與post需要注意的幾點

2021-09-08 14:59:32 字數 3430 閱讀 2615

在面試或者筆試時,經常會被問到 http 方法中 get 和 post 的異同點。本文簡單整理歸納了一下,以備忘。

一些 web 相關職位的面試,無論有沒有提 web,面試中的 get/post,一般就是指 web 中的 get/post。需要注意的是,web 中的 get/post 只是 http 中的 get/post 的子集,所以如果談 get 與 post 的區別,要是面試官有心挖坑,就要特別注意下你們聊的是不是 web 中的 get/post。(本文接下去講的 get/post 基本上是基於 web 的)

其實,http 中的 get 與 post 只是單純的名字上的區別,get 請求的資料也可以放在 request body 中,只是瀏覽器沒有實現它,但是 get 並不只是在 web 中使用。所以,說到 get/post 的區別,會直接條件反射地去說 web 中的 get/post 區別。而 web 中 get 以及 post,其實都可以往服務端傳送資料,get 是將資料拼接在 url 上(有必要時需要 encode),而 post 是將資料封裝在 request body 中,傳送過去。

get/post 可以顧名思義地理解,get 是用來請求資料,那麼,既然是請求資料,為什麼還要帶上資料呢?其實很好理解,比如乙個新聞頁面,有很多內頁,那麼 get 請求可能帶上的類似這樣的引數page=1,即為請求第一頁的資料。post 的話顧名思義就是傳送資料,所以需要帶上資料。

何謂安全?這裡的安全指的是在規範的定義下,get 操作不會修改伺服器的資料,無論做多少次 get 請求,服務端的資料都是不會有變化的,所以說 get 請求是安全的。"get 請求是安全的" 換句話說就是 "get 請求不產生***",它僅僅是獲取資源資訊,就像資料庫查詢一樣,不會修改,增加資料,不會影響資源的狀態。

何謂冪等?冪等是說,同乙個請求原封不動的傳送 n 次和 m 次(n 不等於 m,n 和 m 都大於 1),伺服器上資源的狀態最終是一致的,相應地伺服器返回的內容也是一致的。get 請求是冪等的,因為無論請求多少次,伺服器上的資源狀態不變,而 post 則不然,post 會更新伺服器的資料。比如發貼是非冪等的,重複 10 次發貼請求會建立 10 個帖子。但修改帖子內容是冪等的,乙個修改請求重複無論多少次,帖子最終狀態都是一致的。

關於冪等再舉個數學上的例子。對於單目運算,如果乙個運算對於在範圍內的所有的乙個數多次進行該運算所得的結果和進行一次該運算所得的結果是一樣的,那麼我們就稱該運算是冪等的。比如絕對值運算就是乙個例子,在實數集中,有abs(a)=abs(abs(a))。這個例子非常的好,abs(a) 可以表示做了一次 get 請求後的伺服器上的資源狀態,對其繼續做 abs 運算,狀態不變,這就好比做了一次 get 請求,繼續再做,而該資源狀態一直不變,所以請求得到的東西也就不會變。

因此,按照某一 id 閱覽文章就是安全而冪等的,應當使用 get。而註冊使用者、登入等操作會改變伺服器的資源狀態,不是安全而冪等的,應當使用 post。

這裡的 "安全",和第二點所講的 "安全" 又是兩回事了。這裡的 "安全" 是密碼學上的,也就是大多數場景中 "安全" 的意思。

其實該點頗有點(post)五十步笑(get)百步之嫌。

我們知道,get 請求是將資料附在 url 上,而 post 是將資料封裝在 request body 中。所以 get 請求附加的引數可能會被人在瀏覽器位址列上直接看到,或者檢視一下瀏覽器的歷史記錄或者日誌,就能看到你的引數。而 post 因為不能被快取,也不能被儲存為書籤,所以請求過了就沒有記錄了?請求引數就不能被截獲了?非也,抓個包就可以看到了。

所以,post 請求只是相對安全的。(防君子防不了小人)

http 協議中的 get/post 並沒有傳送資料大小的限制,對傳送資料大小產生限制的是瀏覽器以及作業系統、伺服器,http 本身並沒有對 url 長度有所限制

ie 對 url 長度的限制是 2083位元組(<=ie 8)。對於其他瀏覽器,如 netscape、firefox 等,理論上沒有長度限制,其限制取決於作業系統以及伺服器的支援。而 chrome 遇到長度很長的 url 時,會直接 崩潰。

url 長了,對伺服器處理也是一種負擔。原本乙個會話就沒有多少資料,現在如果有人惡意地構造幾個幾 m 大小的 url,並不停地訪問你的伺服器。伺服器的最大併發數顯然會下降。另一種攻擊方式是,把告訴伺服器 content-length 是乙個很大的數,然後只給伺服器發一點兒資料,嘿嘿,伺服器你就傻等著去吧。哪怕你有超時設定,這種故意的次次訪問超時也能讓伺服器吃不了兜著走。有鑑於此,多數伺服器出於安全啦、穩定啦方面的考慮,會給 url 長度加限制。

理論上講,post 是沒有大小限制的,http 協議規範也沒有進行大小限制,說 "post資料量存在80k/100k 的大小限制" 是不準確的,post 資料是沒有限制的,起限制作用的是伺服器的處理程式的處理能力。

這點非常容易理解,開啟乙個頁面,如果之前開啟過,那麼很明顯速度會加快,這是因為 html/js/css/img 等檔案都能被瀏覽器快取(也可以被伺服器快取),而這些檔案的獲取,都是用的 get 請求。事實上,web 中的絕大多數請求都是用 get 完成的,post 請求目前為止我只是在 ajax 以及 form 表單中有見過。

但是實際上,http 協議中 post 和 get 都是可以被快取的,不過不要驚訝,瀏覽器的實現總是比標準厲害。(post 和 get 真的只有名字上的區別啊。。)

因為 get 請求會有快取,所以在開發過程中,很多時候我們要手動清除快取,不然看不到修改後的樣子。

關於 get 請求能被快取我有個慘痛的經歷。在一次開發中,要做乙個跳轉頁面(假設為 a.index,同時需要在主頁面(假設為 index.htm)中帶個引數(假設為 tmp)過去,為了方便,直接將引數附加在了跳轉頁面的 url 上,頁面位址為 a.htm?tmp,直接取其 location.search 屬性即可獲取引數。之後修改了 a.htm 頁面的內容,但是發現一直不生效,並且已經清除了 a.htm 頁面的快取,排查了很久,原因很顯然,快取位址為 a.htm?tmp,需要清除該位址的快取!

所以一般要獲取最新的檔案(非快取檔案),可以加個類似時間戳一樣的引數。

form 表單有個 method 屬性,一般為 "post"。但是,其實 method 屬性是可以為 "get" 的,甚至,預設就是 "get"。

如果是 "post" 方式,資料藏在 request body 中,如果是 "get" 方式,資料拼接在 url 上。但是,一般 form 表示都與 "資料提交" 相輔相成,會對服務端資料做修改,所以一般都是以 "post" 的方式。

說完 get/post,再來簡單談談他們的其他幾個好**吧。

http 定義了與伺服器互動的不同方法,最基本的方法有 4 種,分別是 get,post,put,delete。url 全稱是資源描述符,我們可以這樣認為:乙個 url 位址,它用於描述乙個網路上的資源,而 http 中的 get,post,put,delete 就對應著對這個資源的查,改,增,刪 4 個操作。

get 和 post 成功之後應該返回 200;而 put 和 delete 在成功時則推薦使用 202.

學習程式設計需要注意的幾點

1 不要死記硬背語法 程式開發的語法 規範特別多,不可能全記下來,只要知道有這麼乙個功能即可,需要的時候再翻書或查詢幫助。這樣省時省力,可以將更多的時間和精力用在技術的提高上。2 多動手,多練習 死讀書是成不了程式設計高手的!只有多練習,多上機編寫程式,才能在實踐中提高對程式設計的認識。3 遇到問題...

Object c block需要注意的幾點問題

摘自 date 2015 12 4 1.block定義 1 說明 a.block是oc中的一種資料型別,在ios開發中被廣泛使用 b.是block的特有標記 c.block的實現 包含在 之間 d.大多情況下,以內聯inline函式的方式被定義和使用 e.block與c語言的函式指標有些相似,但使用...

jquery的 on 函式需要注意的幾點

jquery 的.on 函式允許元素通過 的方式繫結事件,也就是說,子元素通過事件冒泡,把事件傳遞到父元素上進行處理。這也就允許了對動態建立元素的事件繫結。對於.on 函式,有以下幾點值得注意 使用.on函式可以對動態建立的,暫時不存在的元素繫結事件,比如說頁面有乙個 列表,列表裡面的 是通過aja...