Note: Http request

之前看過某些同一個IP 上有多個不同網域Http 服務器且共用80 port,今天看了HTTP 的相關內容,應該是HTTP 的Request 裡面的Header 有一個Host 讓Web Server 可以知道現在到底對應那個Domain, 來回應不同網站內容,就如同可以透過User-Agent 識別是哪種瀏覽器字串,輸出不同的Layout 讓桌面跟行動裝置可以有更佳的操作方式或是支持不同瀏覽器的行為。

而RESTFUL API 目前針對不同的Request method有一些通用/標準化的使用方式定義,需注意的是,對HTTP 方法而言,則是透過Server 跟Client 實作間的約定,沒有強制性,也可以自定義方法

  • GET — 功能主要是跟Server 要資料,對應CRUD 的Read, 因其不改變Server狀態, 單純讀取而已,所以具有安全與冪等性
  • POST — 增加一筆資料到Server上,如果資料已經存在還是會新增一筆,對應CRUD的Create,會改變狀態,而起資料會重複增加,所以安全與冪等性都不存在
  • DELETE — 刪除一筆特定資料,對應CRUD的Delete, 不具安全性,因其改變狀態但是重複執行後,還是無法重複刪除資料,所以不具備安全但具備冪等性
  • PUT — 新增資料,是資料不存在就新增,存在則覆蓋,對應CRUD的Update(Replace),所以一樣是不具安全性但具備冪等性因為重複覆蓋不影響最後結果
  • PATCH — 更新資料,附加資料在已有資料後方,與PUT不同處主要是該資料必須已經是存在的,不具備冪等性與安全性,對應CRUD 的Update(Modify)
  • HEAD — 基本上跟GET差不多,主要是用來讀與Server 的狀態但是不讀取實質資料就只取前方的HEADER而已

HTTP/1.1 文件RFC 2616 的 Section 5 定義一個客戶端的Request 由下列元素組成

  • Request Line — 由Method/URI/HTTP Version + CRLF組成
  • Header — 任意的header區(可以為0) + CRLF
  • CRLF — 最少會有一行CRLF,換行看了提案人估計是Microsoft 的關係
  • Message Body – 大小不定可以為0

基本上設計Web Service 應該需要把HTTPS/1.1 先看過一遍吧,有概略認知後對後續系統設計與運作會比較有全面性認知,應該可以算是打基礎的關鍵定義,至於CoAP and HTTP/2之類的都是延伸增強概念,讓HTTP從本來的人類易讀的明文(PLAIN TEXT)協定,改成因為安全與效率考量的BINARY方式傳輸

Ref.

廣告