一篇關於ajax的故事

前言

我爲何要寫這個呢，之前面試的時候問過這些，還有就是我我的來看，學習前端其實閉包啊，原型啊，等等的問題，被寫爛了，可是關於數據交互這一塊的不多，咱們在業務中，數據交互用的並不佔少數，整理一篇給你們，也給我本身，但願喜歡的點一個關注GitHub

ajax

什麼是ajax

其實呢，提及ajax，你們都不陌生，可是這裏我仍是詳細的介紹一下，也好爲我下一篇博文作基礎，下一篇內容是和數據交互相關的，ajax全稱Asynchronous JavaScript and XML（異步的javascript和XML）,爲何會有這麼一種技術的出現呢，由於前端時常會有這樣的需求，咱們只要局部刷新，不須要整一個刷新的時候，便吹生了這樣的技術ajax，具體它是怎麼實現的咱們下面娓娓道來。

ajax實現的基本流程

其實之前看到過一個變態的面試題，讓你本身寫一個原生的ajax，若是你讓我查接口我能寫的出來，可是讓我默寫我辦不到，由於如今用的基本都是jquery封裝的ajax，確實人家封裝的很好，因此咱們只要懂得了ajax的怎麼實現的基本流程，我以爲對於像我這樣的應屆生夠了。

ajax的基本流程：

• 頁面js腳本實例化一個XMLHttprequest對象
• 設置好服務端給定的url、必要的查詢參數、回調函數等
• 向服務端發起請求，服務端處理請求以後的結果返回給頁面
• 觸發原先訂好的回調函數，來獲取數據

ajax實現局部刷新的流程也是這樣，由於咱們能夠發出ajax向服務器獲取這個局部相關的少許數據，而後運用這部分數據來更新頁面

ajax追本溯源

其實呢，ajax是在2005年由google的Jesse James Garrett發表了一篇文章中提出的，它依賴於XMLHttp實現的，XMLHttp是1998年由微軟提出的，google用ajax開發Google Maps等產品，運用若干年以後，纔在文章中發表，那麼其實ajax是給Google Maps這樣的複雜應用而生的，可是，我想談談ajax帶來的副產品，表單提交

ajax在數據交互中的應用

我以爲ajax用於數據交互，對於我這些初學者更應該把握好兩點，一點是GET和POST的區別，重中之重，還有一點，能夠了解一下什麼是RESTFUL風格，其餘更加深人的能夠結合promise規範，看一下jquery的ajax是怎麼封裝的等等，這篇博文不會寫這些，我打算後期出一篇promise規範相關的，把如今的一些fetch等新出來的數據交互手段進行概括，舉個ajax應用的例子：

$.ajax({
    type: "post",  //數據傳輸的方法
    url: ...,  //通常這裏會是後端給你的接口路徑
     data: {data},//這裏是一個提交的數據內容
    success: function(){}    //成功後進行的操做
    error: function(){}        //數據審覈不經過，後端通常會返回false而後進行的操做複製代碼

GET和POST的區別

碰到同樣東西時，咱們應該先去查文檔，把基本概念搞清楚，而後在開始分析利和弊

• 基本概念

其實在MDN的解釋中就能夠清楚的發現二者的區別：

HTTP GET 方法請求指定的資源。使用 GET 的請求應該只用於獲取數據。

HTTP POST 方法 發送數據給服務器.

• 安全性

關於二者的安全性，這個毋庸置疑，可是你只知道POST是比GET安全，但你不知道，爲何？

深刻了解一點的會發現，get方式的http請求是這樣的

GET

你的參數會被拼接到url上，而後進行傳輸，這樣就會又一個問題，參數都是可見的，就像我截圖的同樣，而POST就不同

POST

塗了點，由於接口是公司的，POST方式url後面是不帶參數的，POST放在Request body中（這點是來自W3C）

• 書籤

GET可做爲書籤收藏，由於參數是拼在URL上的，POST就不能夠了

• 歷史

GET請求的參數能存在瀏覽器歷史中，而POST不能，緣由也在於一個參數是拼接在url中，而一個不是

• 對數據長度的限制

這一點我想要好好談談，GET的數據長度限制來源於哪裏，仍是上面講的一點，GET的參數是拼接在URL中的，理論上URL中的參數是能夠無限加長的，可是這樣勢必會給瀏覽器和服務器帶來很重的負擔，因此業界有一種不成文的規定，大多數瀏覽器在URL的限制是2K，而大多數服務器的限制在64K。
在這點上不少人都會有誤區，咱們得明白一下幾點：

1.http是沒有限制GET和POST的傳遞數據長度的

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

2.規定是來源於瀏覽器和服務器

• 對數據的編碼

這點也是跟GET是拼接在URL上同樣，那麼GET的參數只能進行URL編碼，而POST就不同，能夠進行二進制編碼等

• 性能方面

這個方面就是GET比較出色了，這一點本身也是在整理的時候才關注起來的，不少知識來源於網絡，因此，你們能夠看，若是和你實際狀況不符，能夠在評論中提出：

GET產生一個TCP數據包；POST產生兩個TCP數據包。
對於GET請求來講，是把http header和data一塊兒發送給服務器，而後服務器會返回200。
可是POST就不同，是先發送http header，而後服務器響應100後，在將data發送給服務器，而後服務器響應200

對於性能而言，一個走了一趟，一個走了兩趟，明顯是走一趟的來的快捷

• 總結

所有使用POST明顯是不合理的，在一些數據不敏感，請求頻繁，數據量小於瀏覽器限制2K，這樣的狀況仍是選擇GET會比較合理。

結語

關於RESTful風格，筆者也在探索階段，如今只會書寫，可是爲何是這樣寫的，這樣的格式是怎麼來的，本身也不清楚，哈哈哈，不過，能夠給你們推薦幾本書，有興趣的能夠看一下《REST in Practice》,還有一個是REST風格的提出者發表的論文(英文版)

文章中參考的博文

來源知乎
來源知乎

備註

但願喜歡的朋友點個喜歡，也能夠關注，要是能給博主的GitHub點個star就更好了，你們一塊兒努力，🙏🙏🙏