HTTP協議

• 提問
• 狀態碼
• • • 分類
    • 常見狀態碼
    • 關于協議和規范
• http methods
• • • 傳統的methods
    • 現在的methods
• Restful API
• • • 如何設計成一個資源
    • • 1.盡量不用url參數
      • 2.用method表示操作類型
• http headers
• • • 常見的Request Headers
    • 常見的Response Headers
    • 自定義header
    • 緩存相關的headers
    • http緩存
    • 關于緩存
• http緩存
• • • 強制緩存
    • • Cache-Control
      • Cache-Control的值
      • 關于Expires
    • 協商（對比）緩存
    • • 資源標識
      • Last-Modified
      • Etag
      • Headers示例
      • 請求示例
      • Last-Modified和Etag
      • http緩存綜述流程圖
    • 刷新頁面對http緩存的影響
    • • 三種刷新操作
      • 不同刷新操作，不同的緩存策略

提問

• http常見狀態碼有哪些
• http常見的header有哪些
• 什么是Restful API
• 描述一下http的緩存機制（重要）

狀態碼

分類

• 1xx 服務器收到請求
• 2xx 請求成功，如200
• 3xx 重定向，如302
• 4xx 客戶端錯誤，如404
• 5xx 服務端錯誤 ，如500

常見狀態碼

• 200 成功
• 301 永久重定向（配合location，瀏覽器自動處理）
• 302 臨時重定向（配合location，瀏覽器自動處理）
• 304 資源未被修改，請求資源和之前資源一樣
• 404 資源未找到
• 403 沒有權限
• 500 服務器錯誤
• 504 網關超時，一臺服務器請求另一臺服務器時出錯

關于協議和規范

就是一個約定
要求大家都跟著執行
不要違反規范，如IE瀏覽器

http methods

傳統的methods

• get請求服務器數據
• post向服務器提交數據
• 簡單的網頁功能，就這兩個操作

現在的methods

• get獲取數據
• post新建數據
• patch/put更新數據
• delete刪除數據

Restful API

一種新的API設計方法
傳統API設計：把每個url當做一個功能
Restful API設計：把每個url當做一個唯一的資源

如何設計成一個資源

1.盡量不用url參數

• 傳統的API設計：/api/list?pageIndex=2
• Restful API設計：/api/list/2

2.用method表示操作類型

• 傳統的API設計:
  post請求：/api/create-blog
  post請求：/api/update-blog?id=100
  get請求：/api/get-blog?id=100
• Restful API設計：
  post請求：/api/blog
  patch請求：/api/blog/100
  get請求：/api/blog/100

http headers

常見的Request Headers

• Accept 瀏覽器可接收的數據格式
• Accept-Encoding 瀏覽器可接收的壓縮算法，如gzip
• Accept-Languange 瀏覽器可接收的語言 ，如zh-CN
• Connection：keep-alive一次TCP連接重復使用
• cookie
• Host
• User-Agent（簡稱UA）瀏覽器信息
• Content-type 發送數據的格式，如application/json

常見的Response Headers

• Content-type 返回數據的格式，如application/json
• Content-length 返回數據的大小，多少字節
• Content-Encoding 返回數據的壓縮算法，如gzip
• Set-Cookie

自定義header

headers:{"X-Requested-With":"XMLHttpRequest"}

緩存相關的headers

• Cache-Control
• Expires
• Last-Modified
• If-Modified-Since
• Etag
• If-None-Match

http緩存

• 關于緩存的介紹
• http緩存攻略（強制緩存 + 協商緩存）
• 刷新操作方式，對緩存的影響

關于緩存

• 什么是緩存
• 為什么需要緩存
• 哪些資源可以被緩存？—靜態資源（js、css、img）

http緩存

強制緩存

緩存過期

請求緩存的情況

Cache-Control

• Response Headers中
• 控制強制緩存的邏輯
• 例如Cache-Control：max-age=31536000(單位是秒)

Cache-Control的值

• max-age
• no-cache：不用強制緩存，我們到服務端去請求，服務端怎么處理我們不管
• no-store：我們不用強制緩存，而且我們也不用服務端的一些緩存措施，讓服務端簡單粗暴的將資源再返回我一份
• private：最終用戶做緩存，比如電腦，瀏覽器，手機
• public：中間的路由，中間的代理也可以作為緩存

關于Expires

• 同在Response Headers中
• 同為控制強制緩存的過期
• 已被Cache-Control代替

協商（對比）緩存

• 服務器端緩存策略：服務端來判斷一個資源是不是被緩存
• 服務器判斷客戶端資源，是否和服務端資源一樣
• 一致則返回304，否則返回200和最新的資源
  

資源標識

• 在Response Headers中，有兩種
• Last-Modified 資源的最后修改時間
• Etag 資源的唯一標識 （一個字符串，類似人類的指紋）

Last-Modified

Etag

Headers示例

請求示例

Last-Modified和Etag

• 會優先使用Etag
• Last-Modified只能精確到秒級，而計算機大多毫秒級以內
• 如果資源被重復生成，而內容不變，則Etag更精確

http緩存綜述流程圖

刷新頁面對http緩存的影響

三種刷新操作

• 正常操作：地址欄輸入url，跳轉鏈接，前進后退等
• 手動刷新：F5，點擊刷新按鈕，點擊菜單刷新
• 強制刷新：Ctrl + F5

不同刷新操作，不同的緩存策略

• 正常操作：強制緩存有效，協商緩存有效
• 手動刷新：強制緩存失效，協商緩存有效
• 強制刷新：強制緩存失效，協商緩存失效

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的（十）HTTP协议【前后端分离的时代，网络请求是前端的生命线】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。