Battle！用JavaScript發(fā)出HTTP請求

Battle！用JavaScript發(fā)出HTTP請求的不同方法

文共2678字，預(yù)計學(xué)習(xí)時長15分鐘

圖源：unsplash

使用JavaScript時，總會有各種需要發(fā)出調(diào)用請求的情況，進(jìn)行ajax調(diào)用什么技術(shù)更適合呢？

最初，盡管有一些方法可以在不刷新頁面的情況下從服務(wù)器提取數(shù)據(jù)，但它們通常依賴于笨拙的技術(shù)。直到微軟為Outlook電子郵件客戶端的替代瀏覽器開發(fā)了XMLHttpRequest。它在2006年成為了Web標(biāo)準(zhǔn)。

2015年，F(xiàn)etch API隨ES6引入。通用的Request和Response接口提供了一致性，而Promises允許更容易的鏈接和沒有回調(diào)的異步/等待。Fetch簡潔，優(yōu)雅且易于理解，但是還有其他不錯的選擇，本文將簡要的含義、語法以及利弊。

以下代碼展示了使用不同替代方法的基本HTTP GET和POST示例。現(xiàn)在開始吧~

XMLHttpRequest

XMLHttpRequest對象可用于從Web服務(wù)器請求數(shù)據(jù)。它是這次比較中最早的方法，盡管其他選擇都優(yōu)于它，但由于其向后兼容性和成熟度，它仍然有效且有用。

得到：

var req=new XMLHttpRequest();//The onreadystatechange property
//specifies a function to be
//executed every time the status
//of the XMLHttpRequest changes
req.onreadystatechange=function() {
    if (this.readyState==4 &&this.status==200) {
       //The responseText property
       //returns a text string          
       console.log(xhttp.responseText)
       //Do some stuff
    }
};req.open("GET", "http://dataserver/users", true);
req.send();

發(fā)送：

varformData=new FormData();
formData.append("name", "Murdock");
var req=new XMLHttpRequest();
req.open("POST", "http://dataserver/update");
req.send(formData);

優(yōu)點(diǎn)：

· 不需要從外部源加載

· 向后兼容性

· 成熟/穩(wěn)定

· 在所有瀏覽器中均可使用

· 是原生瀏覽器API

缺點(diǎn)：

· 支持回調(diào)地獄

· 笨拙冗長的語法

· Fetch能自然地替代它

圖源：unsplash

Qwest

Qwest是一個基于Promise的簡單ajax庫，它支持XmlHttpRequest2的獨(dú)立數(shù)據(jù)，例如ArrayBuffer，Blob和FormData。

得到：

qwest.get('http://dataserver/data.json')
     .then(function(xhr, response) {
        // ...do some stuff whith data
     });

發(fā)送：

qwest.post('http://dataserver/update',{
        firstname: 'Murdock',      
        age: 30
     })
     .then(function(xhr, response) {
        // Make some useful actions
     })
     .catch(function(e, xhr, response) {
        // Process the error
     });

優(yōu)點(diǎn)：

· 可以建立請求限制

· 基于Promise

缺點(diǎn)：

· 并非所有瀏覽器上都可使用XmlHttpRequest2

· 非原生

· 必須從外部源加載

JQuery.ajax

該庫在不久前被廣泛用于發(fā)出HTTP異步請求。jQuery的所有Ajax方法都返回XMLHTTPRequest對象的超集

得到：

$.ajax({
    url: 'http://dataserver/data.json'
  }).done(function(data) {
    // ...do some stuff whith data
  }).fail(function() {
    // Handle error
});

發(fā)送：

$.ajax({
  type: "POST",
  url: 'http://dataserver/update',
  data: data,
  success: successCallBack,
  error: errorCallBack,
  dataType: dataType
});

優(yōu)點(diǎn)：

· 良好的支持和文檔

· 可配置的對象

· 在許多項目中使用

· 學(xué)習(xí)曲線低

· 它返回XMLHttpRequest對象，因此可以中止請求

缺點(diǎn)：

· 非原生

· 必須從外部源加載

· 沒有與Promises結(jié)合

· 對于原生ES6 Fetch不是必需的。

Axios

圖源：unsplash

基于Promise的HTTP庫，用于在瀏覽器和Nodejs上執(zhí)行HTTP請求。

得到：

axios({
  url: 'http://dataserver/data.json',
  method: 'get'
})

發(fā)送：

axios.post('http://dataserver/update',{
    name: 'Murdock'
  })
  .then(function (response) {
    console.log(response);
  })
  .catch(function (error) {
    console.log(error);
  });

優(yōu)點(diǎn)：

· 使用promise避免回調(diào)地獄

· 在瀏覽器和Nodejs上均可使用

· 支持上傳進(jìn)度

· 可以設(shè)置響應(yīng)超時

· 通過簡單地向其傳遞配置對象即可配置請求

· Axios已實(shí)現(xiàn)可撤銷的promise提議

· 自動將數(shù)據(jù)轉(zhuǎn)換為JSON

缺點(diǎn)：

· 非原生

· 必須從外部源加載

SuperAgent

SuperAgent是ajax API，旨在提供靈活性，可讀性和較低的學(xué)習(xí)曲線。它也可以與Node.js一起使用。

得到：

request('GET','http://dataserver/data.json').then(
success, failure);

.query（）方法接受對象，這些對象與GET方法一起使用時將形成查詢字符串。以下代碼將產(chǎn)生路徑/ dataserver / search？name=Manny＆lastName=Peck＆order=desc。

request
   .get('/dataserver/search')
   .query({ name: 'Templeton' })
   .query({ lastname: 'Peck' })
   .query({ order: 'desc' })
   .then(res=> {console.dir(res)}
});

發(fā)送：

request
   .post('http://dataserver/update')
   .send({ name: 'Murdock' })
   .set('Accept', 'application/json')
   .then(res=> {
      console.log('result' +JSON.stringify(res.body));
   });

優(yōu)點(diǎn)：

· 基于Promise

· 在Node.js和瀏覽器中均可使用

· 可以調(diào)用request.abort()方法中止請求

· 社區(qū)的知名庫

· 發(fā)出HTTP請求的無縫接口

· 出現(xiàn)故障時支持重試請求

缺點(diǎn)：

· 它不支持以XMLHttpRequest的形式監(jiān)視加載進(jìn)度

· 非原生

· 必須從外部源加載

圖源：unsplash

Http-client

Http-client允許使用JavaScript的訪存API組成HTTP客戶端。

得到：

//usingES6 modules
import { createFetch, base, accept, parse } from 'http-client'const fetch=createFetch(
 base('http://dataserver/data.json'), 
  accept('application/json'),    
  parse('json')                     
)fetch('http://dataserver/data.json').then(response=> {
  console.log(response.jsonData)
})

發(fā)送：

//usingES6 modules
import { createFetch, method, params } from 'http-client'const fetch=createFetch(
  params({ name: 'Murdock' }),
  base('http://dataserver/update')
)

優(yōu)點(diǎn)：

· 在Node.js和瀏覽器中均可使用

· 由服務(wù)器端工作人員使用

· 基于Promise

· 提供頭部保護(hù)裝置，以提高CORS的安全性

缺點(diǎn)：

· 必須從外部源加載

· 非原生

Fetch

Fetch是原生瀏覽器API，用于發(fā)出替代XMLHttpRequest的請求。與XMLHttpRequest相比，F(xiàn)etch使網(wǎng)絡(luò)請求更容易。Fetch API使用Promises避免XMLHttpRequest回調(diào)地獄。

得到：

//WithES6 fetch
fetch('http://dataserver/data.json')
  .then(data=> {
    // ...do some stuff whith data
  }).catch(error=> {
    // Handle error
});

發(fā)送：

fetch('http://dataserver/update',{
  method: 'post',
  headers: {
    'Accept': 'application/json,text/plain, */*',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({name: 'Murdock'})
}).then(res=>res.json())
  .then(res=> console.log(res));//ORwith ES2017 for example(async ()=> {
 
  const response=awaitfetch('http://dataserver/update', {
    method: 'POST',
    headers: {
      'Accept': 'application/json',
      'Content-Type': 'application/json'
    },
    body:JSON.stringify({name='Murdock'})
  });const result=awaitresponse.json();console.log(result);
})();

優(yōu)點(diǎn)：

· 是原生瀏覽器API

· Fetch基本上是經(jīng)過完善的XMLHttpRequest

· 友好且易于學(xué)習(xí)

· 與大多數(shù)最近使用的瀏覽器兼容

· 是原生XMLHttpRequest對象的自然替代

· 學(xué)習(xí)曲線低

· 不需要從外部源加載它

· 使用promises避免回調(diào)地獄

· 不需要更多依賴項

缺點(diǎn)：

· 處理JSON數(shù)據(jù)的過程分為兩步。第一個是發(fā)出請求，然后第二個是在響應(yīng)時調(diào)用.json（）方法。對于Axios，默認(rèn)情況下會收到JSON響應(yīng)。

· 從Fetch()返回的Promise僅在網(wǎng)絡(luò)故障或任何阻止請求完成的情況發(fā)生時拒絕。即使響應(yīng)為HTTP 404或500，也不會拒絕HTTP錯誤狀態(tài)。

· 缺乏其他庫的一些有用功能，例如：取消請求。

· 默認(rèn)情況下，F(xiàn)etch不會從服務(wù)器發(fā)送或接收Cookie，如果站點(diǎn)依賴于維持用戶會話，則會導(dǎo)致未經(jīng)身份驗證的請求。但是可以通過添加以下內(nèi)容來啟用：

{credentials: “same-origin.”}

圖源：unsplash

Fetch是一個新標(biāo)準(zhǔn)，新版本的Chrome和Firefox無需使用任何其他庫就可支持它。

此外，Axios，SuperAgent或其他庫都有適合的文檔，易于使用，并且學(xué)習(xí)曲線不太高。在某些情況下，它們可以提供Fetch不具有的功能。

Fetch在JavaScript里是原生的，足以滿足項目需求。如果沒有特殊需求，我認(rèn)為Fetch就是最合適的選擇。

留言點(diǎn)贊關(guān)注

我們一起分享AI學(xué)習(xí)與發(fā)展的干貨

如轉(zhuǎn)載，請后臺留言，遵守轉(zhuǎn)載規(guī)范

TTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）是互聯(lián)網(wǎng)中使用最廣泛的通信協(xié)議之一，它定義了客戶端與服務(wù)器之間的通信規(guī)則。無論是瀏覽網(wǎng)頁、調(diào)用 API、下載文件，還是進(jìn)行各種在線交互，HTTP 都是不可或缺的基礎(chǔ)協(xié)議。HTTP 協(xié)議基于請求-響應(yīng)模型工作，其中客戶端發(fā)出請求，服務(wù)器返回響應(yīng)。HTTP 請求方法定義了客戶端希望執(zhí)行的操作類型，每種請求方法都有特定的用途和行為。

在 HTTP/1.1 中，標(biāo)準(zhǔn)定義了多種請求方法，每種方法適用于不同的場景。本文將詳細(xì)介紹九種 HTTP 請求方法：GET、POST、PUT、DELETE、PATCH、HEAD、CONNECT、OPTIONS 和 TRACE。這些方法在 Web 開發(fā)和 API 設(shè)計中扮演著重要角色。通過理解這些請求方法的功能和使用場景，開發(fā)者可以更好地設(shè)計和優(yōu)化網(wǎng)絡(luò)應(yīng)用程序。

GET 方法

GET 方法是 HTTP 中最常用的請求方法之一，幾乎在所有的 Web 應(yīng)用中都能看到它的身影。GET 請求的主要作用是從服務(wù)器獲取資源，例如網(wǎng)頁、圖片、視頻等。當(dāng)用戶在瀏覽器中輸入一個 URL 并按下回車鍵時，瀏覽器便會向服務(wù)器發(fā)送一個 GET 請求，要求獲取該 URL 對應(yīng)的資源。服務(wù)器處理請求后，會將資源發(fā)送回客戶端，通常是 HTML、CSS、JavaScript 文件或其他媒體內(nèi)容。

GET 方法的主要作用是從服務(wù)器請求數(shù)據(jù)，而不會對服務(wù)器上的資源進(jìn)行任何修改。換句話說，GET 請求是"無副作用"的，不會改變服務(wù)器的狀態(tài)。GET 請求通常用于以下場景：

獲取網(wǎng)頁內(nèi)容：瀏覽器向服務(wù)器請求 HTML 文件以顯示網(wǎng)頁內(nèi)容。
獲取 API 數(shù)據(jù)：客戶端向 API 發(fā)送 GET 請求以獲取數(shù)據(jù)，例如獲取用戶信息、商品列表等。
加載資源文件：獲取靜態(tài)資源，如圖片、CSS、JavaScript 文件等。

示例：

GET /index.html HTTP/1.1
Host: www.example.com

在上述示例中，客戶端通過 GET 請求從服務(wù)器獲取 index.html 文件。服務(wù)器在處理該請求后，會返回相應(yīng)的 HTML 文件給客戶端。

GET 請求廣泛應(yīng)用于 Web 開發(fā)中，尤其是在需要從服務(wù)器獲取數(shù)據(jù)的場景中。例如：

搜索引擎：用戶在搜索引擎中輸入關(guān)鍵詞并按下搜索按鈕時，搜索引擎會向服務(wù)器發(fā)送一個 GET 請求，并將用戶輸入的關(guān)鍵詞附加在 URL 中。服務(wù)器根據(jù)關(guān)鍵詞返回搜索結(jié)果頁面。

示例：

GET /search?q=http GET method HTTP/1.1
Host: www.searchengine.com

在線商店：用戶瀏覽商品時，客戶端會向服務(wù)器發(fā)送 GET 請求，以獲取商品詳情信息。服務(wù)器響應(yīng)包含商品的名稱、價格、描述等信息。

示例：

GET /product/12345 HTTP/1.1
Host: www.onlinestore.com

GET 請求的一個重要特性是可以被緩存。瀏覽器或中間代理服務(wù)器可以緩存 GET 請求的響應(yīng)，以減少重復(fù)請求服務(wù)器的次數(shù)，從而提高性能并降低帶寬消耗。HTTP 協(xié)議中定義了多種緩存機(jī)制，例如 ETag、Last-Modified 等，它們用于標(biāo)識資源的狀態(tài)，判斷資源是否已改變。

緩存示例：

GET /logo.png HTTP/1.1
Host: www.example.com
If-None-Match: "abc123"

如果服務(wù)器返回的 ETag 與緩存中的 ETag 匹配，瀏覽器將直接使用緩存中的資源，而不重新下載文件。這不僅節(jié)省了帶寬，還加快了頁面加載速度。

GET 請求中常見的一種形式是通過 URL 參數(shù)或查詢字符串傳遞數(shù)據(jù)。查詢字符串通常附加在 URL 的末尾，以 ? 開頭，參數(shù)與值之間用 = 連接，多個參數(shù)之間用 & 分隔。

示例：

GET /search?q=HTTP+GET+method&sort=latest HTTP/1.1
Host: www.example.com

在上述請求中，查詢字符串 q=HTTP+GET+method&sort=latest 包含了兩個參數(shù)：q 和 sort，分別表示搜索關(guān)鍵詞和排序方式。這種方式適合傳遞簡單的鍵值對數(shù)據(jù)，但由于查詢字符串會暴露在 URL 中，因此不適合傳輸敏感信息。

盡管 GET 請求廣泛使用，但在安全性方面需要注意以下幾點(diǎn)：

敏感數(shù)據(jù)的暴露：由于 GET 請求的數(shù)據(jù)被附加在 URL 中，查詢字符串中的信息會記錄在瀏覽器歷史記錄、服務(wù)器日志以及第三方代理服務(wù)器中。因此，不應(yīng)通過 GET 請求傳輸密碼、信用卡號等敏感信息。
URL 長度限制：不同瀏覽器和服務(wù)器對 URL 長度的支持有限制，通常在 2048 字符以內(nèi)。如果查詢字符串過長，可能會導(dǎo)致請求失敗。
請求重放：由于 GET 請求是冪等的（即相同的請求無論執(zhí)行多少次，結(jié)果應(yīng)一致），因此容易受到重放攻擊（Replay Attack）。惡意用戶可以通過重復(fù)發(fā)送同一 GET 請求來獲取敏感數(shù)據(jù)或進(jìn)行未授權(quán)的操作。

為了增強(qiáng)安全性，建議在傳輸敏感數(shù)據(jù)時使用 POST 方法，并通過 HTTPS 加密通信。

POST 方法

POST 方法用于向服務(wù)器發(fā)送數(shù)據(jù)，通常是為了提交表單、上傳文件、或調(diào)用 API 接口以進(jìn)行數(shù)據(jù)處理。與 GET 方法不同，POST 請求的數(shù)據(jù)不會附加在 URL 中，而是包含在請求體中。因此，POST 方法適合傳輸較大或敏感的數(shù)據(jù)。

POST 方法的典型使用場景包括：

提交表單數(shù)據(jù)：用戶在網(wǎng)頁上填寫表單后，點(diǎn)擊提交按鈕，瀏覽器會使用 POST 方法將表單數(shù)據(jù)發(fā)送到服務(wù)器。例如，用戶注冊、登錄、提交評論等操作都通常使用 POST 方法。

示例：

POST /submit-form HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded

username=johndoe&password=secret123

上傳文件：POST 方法可以用于將文件上傳到服務(wù)器。在這種情況下，請求體會包含文件數(shù)據(jù)，服務(wù)器處理后保存文件。

示例：

POST /upload HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
  
------WebKitFormBoundary
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg

(binary file data)
------WebKitFormBoundary--

調(diào)用 API：在 RESTful API 中，POST 方法通常用于創(chuàng)建新資源。例如，創(chuàng)建新的用戶賬戶、發(fā)布新的文章或評論等。

示例：

POST /api/users HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "username": "johndoe",
  "email": "johndoe@example.com",
  "password": "secret123"
}

POST 請求是非冪等的，這意味著重復(fù)發(fā)送相同的 POST 請求可能會產(chǎn)生不同的結(jié)果。例如，重復(fù)提交訂單或評論可能會導(dǎo)致服務(wù)器生成多個相同的記錄。由于這一特性，開發(fā)者在設(shè)計 API 時通常需要考慮如何防止重復(fù)提交的問題，例如使用唯一性約束、token 驗證等手段。

與 GET 請求相比，POST 請求在安全性方面有一些顯著的優(yōu)勢：

數(shù)據(jù)不暴露在 URL 中：由于 POST 請求的數(shù)據(jù)包含在請求體中，不會暴露在 URL 中，因此更適合傳輸敏感數(shù)據(jù)，如密碼、信用卡信息等。
數(shù)據(jù)量不受 URL 長度限制：POST 請求的數(shù)據(jù)量沒有像 GET 請求那樣受到 URL 長度的限制，因此可以傳輸較大的數(shù)據(jù)包，如文件上傳、復(fù)雜表單提交等。

盡管如此，POST 請求仍然需要配合 HTTPS 協(xié)議使用，以確保數(shù)據(jù)在傳輸過程中的安全性。使用 HTTPS 可以加密數(shù)據(jù)，防止在傳輸過程中被竊取或篡改。

PUT 方法

PUT 方法通常用于更新服務(wù)器上的資源。與 POST 方法不同，PUT 請求是冪等的，意味著多次發(fā)送相同的 PUT 請求，服務(wù)器的資源狀態(tài)不會變化。PUT 方法可以用于創(chuàng)建或更新資源，通常用于更新現(xiàn)有資源的數(shù)據(jù)。

PUT 方法的典型使用場景包括：

更新用戶信息：用戶修改個人資料時，客戶端通過 PUT 請求將更新后的信息發(fā)送到服務(wù)器，服務(wù)器接收后更新數(shù)據(jù)庫中的用戶信息。

示例：

PUT /api/users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "username": "johndoe",
  "email": "newemail@example.com"
}

更新文檔內(nèi)容：在協(xié)作編輯工具中，用戶保存編輯后的文檔時，客戶端通過 PUT 請求將文檔內(nèi)容上傳到服務(wù)器，服務(wù)器接收后更新文檔存儲。

示例：

PUT /documents/456 HTTP/1.1
Host: www.example.com
Content-Type: text/plain

Updated document content...

PUT 方法是冪等的，這意味著相同的 PUT 請求無論執(zhí)行多少次，服務(wù)器上的資源狀態(tài)應(yīng)保持一致。例如，用戶修改個人資料后，如果重復(fù)發(fā)送相同的 PUT 請求，服務(wù)器上該用戶的資料應(yīng)保持不變，而不會生成多個相同的記錄。

PUT 請求通常用于更新現(xiàn)有資源，因此在安全性方面需要特別注意以下幾點(diǎn)：

身份驗證與授權(quán)：由于 PUT 請求涉及資源的修改，服務(wù)器應(yīng)確保請求方具備修改該資源的權(quán)限。例如，用戶只能修改自己的資料，而不能修改其他用戶的資料。通常，通過身份驗證和授權(quán)機(jī)制來確保這一點(diǎn)。
數(shù)據(jù)完整性：PUT 請求通常要求客戶端發(fā)送完整的資源數(shù)據(jù)，而不僅僅是需要更新的字段。因此，如果網(wǎng)絡(luò)傳輸中數(shù)據(jù)被截斷或丟失，可能導(dǎo)致資源數(shù)據(jù)不完整。為確保數(shù)據(jù)完整性，建議使用校驗和或數(shù)字簽名進(jìn)行數(shù)據(jù)驗證。

DELETE 方法

DELETE 方法用于刪除服務(wù)器上的指定資源。在 RESTful API 設(shè)計中，DELETE 方法通常用于移除指定的資源對象或數(shù)據(jù)。例如，刪除一篇文章、一條評論、或一個用戶賬戶等。DELETE 方法的冪等性特性決定了無論同一個 DELETE 請求被執(zhí)行多少次，服務(wù)器上的資源狀態(tài)應(yīng)保持一致，即資源被刪除后，再次刪除操作不會產(chǎn)生任何新的效果。

DELETE 方法的典型使用場景包括：

刪除用戶賬戶：當(dāng)用戶決定注銷自己的賬戶時，客戶端可以發(fā)送一個 DELETE 請求到服務(wù)器，要求刪除該用戶的賬戶信息。示例： DELETE /api/users/123 HTTP/1.1 Host: www.example.com
刪除文件或記錄：在文件管理系統(tǒng)或數(shù)據(jù)庫管理系統(tǒng)中，DELETE 方法常用于刪除指定的文件或數(shù)據(jù)庫記錄。示例： DELETE /api/files/456 HTTP/1.1 Host: www.example.com

DELETE 方法是冪等的，這意味著相同的 DELETE 請求無論執(zhí)行多少次，服務(wù)器上的資源狀態(tài)應(yīng)保持一致。例如，發(fā)送 DELETE 請求刪除一篇文章，如果文章已經(jīng)被刪除，再次發(fā)送相同的 DELETE 請求不會導(dǎo)致新的變化，服務(wù)器應(yīng)返回一個指示資源已不存在的響應(yīng)。

DELETE 請求涉及到資源的刪除操作，因此需要特別注意以下幾個方面的安全性問題：

身份驗證與授權(quán)：由于 DELETE 操作可能對系統(tǒng)或用戶數(shù)據(jù)造成不可逆的影響，服務(wù)器應(yīng)確保只有有權(quán)限的用戶才能執(zhí)行該操作。例如，用戶只能刪除自己的評論或賬戶，而管理員可能有權(quán)刪除任何用戶的評論或賬戶。
數(shù)據(jù)備份：由于 DELETE 操作的不可逆性，建議在執(zhí)行刪除操作前進(jìn)行數(shù)據(jù)備份，或者設(shè)計成軟刪除，即標(biāo)記數(shù)據(jù)為已刪除，而不是實(shí)際刪除，以便在必要時進(jìn)行恢復(fù)。
防止誤操作：為了防止用戶或系統(tǒng)誤操作刪除數(shù)據(jù)，通常可以設(shè)計確認(rèn)機(jī)制，例如在刪除前要求用戶確認(rèn)操作，或者使用延遲刪除機(jī)制，給用戶一定時間撤銷刪除操作。

PATCH 方法

PATCH 方法用于對服務(wù)器上的資源進(jìn)行部分更新。與 PUT 方法不同，PATCH 請求不需要包含完整的資源數(shù)據(jù)，而只需要傳輸需要更新的部分字段。因此，PATCH 方法非常適合用于需要頻繁更新部分?jǐn)?shù)據(jù)的場景。

PATCH 方法的典型使用場景包括：

更新用戶部分信息：例如，用戶想要修改個人資料中的某一項字段，如郵箱地址或電話號碼，客戶端可以通過 PATCH 請求僅傳輸需要更新的字段，服務(wù)器接收后更新相關(guān)字段的數(shù)據(jù)。

示例：

PATCH /api/users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "email": "newemail@example.com"
}

更新文檔部分內(nèi)容：在文檔管理系統(tǒng)中，如果需要對某篇文檔的部分內(nèi)容進(jìn)行更新，而不修改其他部分，可以使用 PATCH 方法傳輸更新的部分。

示例：

PATCH /documents/456 HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "title": "Updated Document Title"
}

PATCH 方法通常被認(rèn)為是非冪等的，這意味著相同的 PATCH 請求被執(zhí)行多次可能會產(chǎn)生不同的結(jié)果。例如，如果一個 PATCH 請求是對字符串?dāng)?shù)據(jù)進(jìn)行追加操作，那么重復(fù)執(zhí)行相同的請求將會導(dǎo)致字符串的內(nèi)容被多次追加，產(chǎn)生不同的結(jié)果。

然而，也有特定情況下的 PATCH 請求是冪等的，例如只是對某個字段的值進(jìn)行覆蓋更新。在這種情況下，PATCH 請求的冪等性與 PUT 方法類似。

PATCH 請求主要用于部分更新，因此在安全性方面需注意以下幾點(diǎn)：

身份驗證與授權(quán)：服務(wù)器應(yīng)確保只有有權(quán)限的用戶才能執(zhí)行 PATCH 操作。例如，用戶只能更新自己的資料，而不能更新其他用戶的資料。
數(shù)據(jù)驗證與完整性：由于 PATCH 請求只傳輸部分?jǐn)?shù)據(jù)，服務(wù)器在接收到請求后應(yīng)確保數(shù)據(jù)的完整性，并驗證更新后的數(shù)據(jù)是否符合業(yè)務(wù)規(guī)則或約束條件。
避免數(shù)據(jù)競爭：在并發(fā)操作的場景下，如果多個 PATCH 請求同時對同一個資源進(jìn)行不同的部分更新，可能會導(dǎo)致數(shù)據(jù)競爭問題。因此，建議在并發(fā)操作中使用鎖機(jī)制或樂觀鎖策略，以避免數(shù)據(jù)不一致問題。

HEAD 方法

HEAD 方法與 GET 方法非常相似，但它只請求資源的首部信息，而不包含資源的具體內(nèi)容。HEAD 請求的響應(yīng)中只有狀態(tài)行和頭部字段，不返回消息體。HEAD 方法通常用于在不下載資源的情況下獲取資源的元數(shù)據(jù)，如檢查資源是否存在、獲取資源的大小或類型等。

HEAD 方法的典型使用場景包括：

檢查資源是否存在：在下載文件之前，客戶端可以通過 HEAD 請求檢查文件是否存在，并獲取文件的元數(shù)據(jù)，如文件大小、類型等。

示例：

HEAD /files/sample.pdf HTTP/1.1
Host: www.example.com

獲取資源的元數(shù)據(jù)：在不獲取資源內(nèi)容的情況下，客戶端可以使用 HEAD 方法獲取資源的元數(shù)據(jù)，如 Content-Type、Last-Modified、Content-Length 等。

示例：

HEAD /api/documents/456 HTTP/1.1
Host: www.example.com

HEAD 方法的一個顯著特點(diǎn)是它不會返回消息體，因此在獲取資源元數(shù)據(jù)時，HEAD 請求比 GET 請求更加高效。此外，由于 HEAD 請求不會返回資源內(nèi)容，它通常被用作緩存控制的手段。例如，通過 HEAD 請求檢查資源的 Last-Modified 或 ETag 頭部字段，客戶端可以決定是否需要重新下載資源。

CONNECT 方法

CONNECT 方法用于建立一個到服務(wù)器的隧道連接，通常用于 HTTP 與 HTTPS 的代理請求。CONNECT 請求會將客戶端的連接轉(zhuǎn)換為一個雙向通信的通道，允許客戶端與目標(biāo)服務(wù)器之間傳遞任意數(shù)據(jù)而不受代理服務(wù)器的影響。最常見的應(yīng)用場景是通過 HTTP 代理訪問 HTTPS 站點(diǎn)。

CONNECT 方法的典型使用場景包括：

代理 HTTPS 請求：在訪問 HTTPS 網(wǎng)站時，客戶端通過 HTTP 代理發(fā)送 CONNECT 請求，代理服務(wù)器創(chuàng)建一個到目標(biāo)服務(wù)器的隧道連接，使客戶端與目標(biāo)服務(wù)器之間的通信得以加密且直接傳輸。

示例：

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com

當(dāng)代理服務(wù)器收到這個請求后，會建立一個與目標(biāo)服務(wù)器的 TCP 連接，并將后續(xù)的所有數(shù)據(jù)直接傳遞給目標(biāo)服務(wù)器。這種方式允許客戶端與目標(biāo)服務(wù)器之間的通信保持安全性和私密性，因為代理服務(wù)器只負(fù)責(zé)傳遞數(shù)據(jù)，而不進(jìn)行解析或修改。

由于 CONNECT 方法用于創(chuàng)建一個隧道連接，它能夠有效地維護(hù)客戶端與服務(wù)器之間的通信隱私。然而，CONNECT 方法也可能被濫用。例如，惡意用戶可以利用 CONNECT 方法繞過防火墻或其他網(wǎng)絡(luò)安全措施，進(jìn)行未經(jīng)授權(quán)的訪問。因此，許多代理服務(wù)器在使用 CONNECT 方法時會對目標(biāo)端口或目標(biāo)域名進(jìn)行限制，防止濫用。

OPTIONS 方法

OPTIONS 方法用于查詢服務(wù)器支持的請求方法或特定資源所支持的功能。它通常用于檢查服務(wù)器的能力，確定哪些請求方法可以被安全地執(zhí)行在指定資源上。OPTIONS 請求的響應(yīng)通常包括 Allow 頭部字段，列出服務(wù)器支持的請求方法。

OPTIONS 方法的典型使用場景包括：

跨域資源共享（CORS）預(yù)檢請求：在跨域請求中，瀏覽器會自動發(fā)送一個 OPTIONS 請求來預(yù)檢目標(biāo)服務(wù)器是否允許實(shí)際的請求方法。服務(wù)器通過 OPTIONS 請求響應(yīng)，指示是否允許實(shí)際請求繼續(xù)執(zhí)行。

示例：

OPTIONS /api/users HTTP/1.1
Host: api.example.com

響應(yīng)示例：

HTTP/1.1 204 No Content
Allow: GET, POST, PUT, DELETE

查詢服務(wù)器支持的請求方法：客戶端可以使用 OPTIONS 請求查詢服務(wù)器支持哪些請求方法，幫助開發(fā)者了解服務(wù)器的功能和限制。

示例：

OPTIONS /documents/456 HTTP/1.1
Host: www.example.com

響應(yīng)示例：

HTTP/1.1 200 OK
Allow: GET, POST, DELETE, OPTIONS

OPTIONS 方法廣泛用于 CORS 機(jī)制中，以確保跨域請求的安全性和合規(guī)性。通過預(yù)檢請求，服務(wù)器可以控制哪些外部來源和請求方法可以訪問其資源，從而避免跨站請求偽造（CSRF）攻擊。

此外，OPTIONS 方法也可以用于測試和診斷服務(wù)器的配置，幫助開發(fā)者或管理員了解服務(wù)器的請求處理能力。

TRACE 方法

TRACE 方法用于在服務(wù)器上發(fā)起一個回環(huán)測試，即服務(wù)器將收到的請求原樣返回給客戶端。TRACE 方法的主要用途是診斷或調(diào)試，幫助客戶端檢查請求在傳輸過程中是否被修改或損壞。

TRACE 請求的典型使用場景包括：

檢查代理服務(wù)器行為：當(dāng)客戶端與服務(wù)器之間有多個代理服務(wù)器時，TRACE 請求可以用于檢查請求在經(jīng)過各個代理服務(wù)器時是否被修改，幫助診斷網(wǎng)絡(luò)問題。

示例：

TRACE /api/resource HTTP/1.1
Host: www.example.com

響應(yīng)示例：

HTTP/1.1 200 OK
Content-Type: message/http

TRACE /api/resource HTTP/1.1
Host: www.example.com
User-Agent: MyBrowser/1.0

由于 TRACE 方法會將請求的所有信息，包括可能包含的敏感數(shù)據(jù)，如 Cookies 或 Authorization 頭部，返回給客戶端，這可能導(dǎo)致信息泄露。攻擊者可以利用 TRACE 方法實(shí)施跨站點(diǎn)跟蹤攻擊（Cross-Site Tracing，XST），獲取用戶的敏感信息。因此，許多現(xiàn)代的 Web 服務(wù)器默認(rèn)禁用 TRACE 方法以防止?jié)撛诘陌踩L(fēng)險。

TTP（超文本傳輸協(xié)議）請求過程是客戶端（通常是瀏覽器）與服務(wù)器之間通信的方式，用于從服務(wù)器請求資源（如網(wǎng)頁、圖片、視頻等）。以下是HTTP請求的基本步驟：

建立TCP連接：

如果是HTTP/1.1或HTTP/2，首先需要通過TCP協(xié)議建立一個到服務(wù)器的連接。

發(fā)送HTTP請求：

客戶端構(gòu)建一個HTTP請求消息，包括請求行（如GET /index.html HTTP/1.1）、請求頭（包含額外信息如用戶代理、接受語言等）和可能的請求體（對于POST請求）。

請求行：

請求行包含HTTP方法（如GET、POST、PUT、DELETE等）、請求的資源路徑和HTTP版本。

請求頭：

請求頭包含一系列鍵值對，提供關(guān)于請求的附加信息，如Host（服務(wù)器域名）、User-Agent（客戶端瀏覽器信息）、Accept（客戶端可接受的數(shù)據(jù)類型）等。

請求體：

對于某些HTTP方法（如POST、PUT），請求體包含發(fā)送給服務(wù)器的數(shù)據(jù)。

服務(wù)器處理請求：

服務(wù)器接收到HTTP請求后，根據(jù)請求的資源和方法進(jìn)行處理，如查詢數(shù)據(jù)庫、執(zhí)行服務(wù)器端腳本等。

發(fā)送HTTP響應(yīng)：

服務(wù)器處理完請求后，會構(gòu)建一個HTTP響應(yīng)消息，包括狀態(tài)行（如HTTP/1.1 200 OK）、響應(yīng)頭（包含信息如Content-Type、Content-Length等）和響應(yīng)體（通常是請求的資源，如HTML文檔）。

客戶端接收響應(yīng)：

客戶端接收到服務(wù)器的響應(yīng)后，根據(jù)狀態(tài)碼（如200表示成功，404表示未找到等）和響應(yīng)頭處理響應(yīng)體。

內(nèi)容解析與渲染：

對于HTML文檔，客戶端（瀏覽器）會解析HTML、CSS，并執(zhí)行JavaScript代碼，將內(nèi)容渲染到屏幕上。

關(guān)閉TCP連接：

如果是HTTP/1.1的非持久連接，數(shù)據(jù)傳輸完成后，TCP連接會被關(guān)閉。如果是持久連接，同一個TCP連接可以用于多個請求。

資源加載：

如果頁面需要加載其他資源（如圖片、CSS文件、JavaScript文件等），對于每個資源，客戶端會重復(fù)上述HTTP請求過程。

執(zhí)行JavaScript：

頁面中的JavaScript可能會觸發(fā)額外的HTTP請求，如AJAX調(diào)用，用于與服務(wù)器交換數(shù)據(jù)并更新頁面內(nèi)容。

HTTP請求過程是Web通信的基礎(chǔ)，它允許客戶端通過簡單、標(biāo)準(zhǔn)化的方法與服務(wù)器交互，獲取或發(fā)送數(shù)據(jù)。

在線咨詢

上一篇：HTML思想
下一篇：css隱藏頁面元素的多種方法

您的項目需求

*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商

Battle！用JavaScript發(fā)出HTTP請求

XMLHttpRequest

Qwest

JQuery.ajax

Axios

SuperAgent

Http-client

Fetch

GET 方法

POST 方法

PUT 方法

DELETE 方法

PATCH 方法

HEAD 方法

CONNECT 方法

OPTIONS 方法

TRACE 方法

您的項目需求