瀏覽器發起HTTP請求的典型場景
a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads
for flexible interaction with network-based hypertext information systems(RFC7230 2014.6)
一種無狀態的、應用層的、以請求/應答方式運行的協議，它使用可擴展的語義和自描述消息格式，與基於網絡的超文本信息系統靈活的互動
HTTP協議格式
ABNF（擴充巴科斯-瑙爾范式）
ABNF（擴充巴科斯-瑙爾范式）操作符
ABNF（擴充巴科斯-瑙爾范式）核心規則
基於ABNF描述的HTTP協議格式
OSI（Open System Interconnection Reference Model）概念模型
OSI 模型與TCP/IP模型對照
報文頭部在OSI 模型與TCP/IP模型傳輸
評估Web架構的關鍵屬性
架構屬性：性能
架構屬性：可修改性
REST架構下的Web
WAIS 知識點補充
WAIS 是一個Internet系統，在這個系統中，需要在多個服務器上創建專用主題數據庫，該系統可以通過服務器目錄對各個服務器進行跟蹤，並且允許用戶通過WAIS客戶端程序對信息進行查找。
WAIS用戶可以獲得一系列的分布式數據庫，當用戶輸入一個對某一個數據庫進行查詢的信息時，客戶端就會訪問所有與該數據庫相關的服務器。
訪問的結果提供給用戶的是滿足要求的所有文本的描述，此時用戶就可以根據這些信息得到整個文本文件了。
WAIS使用的是自己的Internet,這個<協議是Z39.50標准（國際信息標准組織制定的標准）的擴展。
Web用戶可以下載一個WAIS客戶機程序和一個“網關”到Web瀏覽器，或者通過遠程登錄,連接到一個公共的WAIS客戶機，這樣就可以使用WAIS了。
由於豐富的服務器文件以及搜索引擎現已存在，所以大多數的Web用戶將會覺得WAIS是多余的。
但是，對於圖書管理員、醫學研究員還有其他一些人，他們可以通過WAIS可以得到一些在現有Web上沒有的專業信息。
5種架構風格
數據流風格 Data-flow Styles
管道和過濾器（Pipe and Filter，PF）
每個組件（過濾器）從其輸入端讀取數據流並在其輸出端產生數據流，通常對輸入流應用一種轉換並增量地處理它們，以使輸出在輸入被完全處理完之前就能夠開始。這種風格也被稱作單路數據流網絡（one-way data flow network）。
統一管道和過濾器（Uniform Pipe and Filter，UPF）
該風格在 PF 風格的基礎上，添加了一個約束，即所有過濾器必須具有相同的接口。
復制風格Replication Styles
復制倉庫（Replicated Repository，RR）
基於復制倉庫風格的系統通過利用多個進程提供相同的服務，來改善數據的可訪問性和服務的可伸縮性。
這些分散的服務器交互為客戶端制造出只有一個集中的服務的“幻覺”。主要的例子包括諸如 XMS 這樣的分布式文件系統和 CVS這樣的遠程版本控制系統。
緩存（Cache，$）
復制倉庫風格的一種變體是緩存風格，復制個別請求的結果，以便可以被后面的請求重用。
分層風格Hierarchical Styles
客戶-服務器（Client-Server，CS）
該風格在基於網絡的應用的架構風格中最為常見。服務器組件提供了一組服務，並監聽對這些服務的請求。客戶端組件通過一個連接器將請求發送到服務器，希望執行一個服務。服務器可以拒絕這個請求，也可以執行這個請求並將響應發送回客戶端。
分層系統（Layered System，LS）
一個分層系統是按照層次來組織的，每一層為在其之上的層提供服務，並且使用在其之下的層所提供的服務。盡管分層系統被看作一種“單純”的風格，但是它在基於網絡的
系統中的使用僅限於與客戶-服務器風格相結合，形成分層-客戶-服務器風格。分層系統的例子包括分層通信協議的處理，例如 TCP/IP 和OSI 協議棧。
分層-客戶-服務器（LayeredClient-Server，LCS）
該風格在客戶-服務器風格的基礎上添加了代理（proxy）組件和網關（gateway）組件。一個代理組件作為一個或多個客戶端組件的共享服務器，它接收請求並進行可能的轉換后將其轉發給服務器。一個網關組件在客戶端或代理看起來像是一個正常的服務器，但是事實上它將請求進行可能的轉換后轉發給了它的“內部層”（inner- layer）服務器。這些額外的中間組件添加了很多個層，用來為系統添加諸如負載均衡和安全性檢查這樣的功能。
客戶-無狀態-服務器（Client-Stateless-Server，CSS）
該風格源自客戶-服務器風格，並且添加了額外的約束：在服務器組件之上不允許有會話狀態（session state）。從客戶端發到服務器的每個請求必須包含理解請求所必需的全部信息，不能利用任何保存在服務器上的上下文（context），會話狀態全部保存在客戶端。
客戶-緩存-無狀態-服務器（Client-Cache-Stateless-Server，C$SS）
該風格來源於客戶-無狀態-服務器風格和緩存風格（通過添加緩存組件）。
分層-客戶-緩存-無狀態-服務器（Layered-Client-Cache-StatelessServer，LC$SS）
該風格通過添加代理或網關組件，繼承了分層-客戶-服務器風格和客戶-緩存-無狀態-服務器風格。使用此風格的范例系統是 Internet 域名系統（DNS）。
遠程會話（Remote Session，RS）
該風格是客戶-服務器風格的一種變體，它試圖使客戶端組件（而非服務器組件）的復雜性最小化或者使得它們的可重用性最大化。每個客戶端在服務器上啟動一個會話，然后調用服務器的一系列服務，最后退出會話。應用狀態被完全保存在服務器上。這種風格通常在以下場合中使用：想要使用一個通用的客戶端（例如 TELNET）或者通過一個模仿通用客戶端的接口（例如 FTP ）來訪問遠程服務。
遠程數據訪問（Remote Data Access，RDA）
該風格是客戶-服務器風格的一種變體，它將應用狀態分布在客戶端和服務器上。客戶端以一種標准的格式發送一個數據庫查詢（例如 SQL）請求到服務器，服務器分配一個工作空間並執行這個查詢，這可能會導致一個巨大的結果集。客戶端能夠在結果集上進行進一步操作（例如表連接）或者每次獲取結果的一部分。客戶端必須了解服務的數據結構，以便建造依賴於該結構的查詢。
移動代碼風格 Mobile Code Styles
虛擬機（Virtual Machine，VM）
所有移動代碼風格的基礎是虛擬機（或解釋器）風格。代碼必須以某種方式來執行，首選的方式是在一個滿足了安全性和可靠性關注點的受控環境中執行，而這正是虛擬機風格所提供的。
遠程求值（Remote Evaluation，REV）
該風格來源於客戶-服務器風格和虛擬機風格，一個客戶端組件必須要知道如何來執行一個服務，但缺少執行此服務所必需的資源（CPU 周期、數據源等等），這些資源恰好位於一個遠程站點上。因此，客戶端將如何執行服務的代碼發送給遠程站點上的一個服務器組件，服務器組件使用可用的資源來執行代碼，然后將執行結果發送回客戶端。
按需代碼（Code on Demand，COD）
在該風格中，一個客戶端組件知道如何訪問一組資源，但不知道如何處理它們。它向一個遠程服務器發送對於如何處理資源的代碼的請求，接收這些代碼，然后在本地執行這些代碼。
分層-按需代碼-客戶-緩存-無狀態-服務器（Layered-Code-on-DemandClient-Cache-Stateless-Server，LCODC$SS）
將按需代碼風格添加到上面討論過的分層-客戶-緩存-無狀態-服務器風格上。因為代碼被看作不過是另一種數據元素，因此這並不會妨礙LC$SS 風格的優點。
移動代理（Mobile Agent，MA）
在該風格中，一個完整的計算組件，與它的狀態、必需的代碼、執行任務所需的數據一起被移動到遠程站點。該風格可以看作來源於遠程求值風格和按需代碼風格，因為移動性是同時以這兩種方式工作的。
點對點風格Peer-to-Peer Styles
基於事件的集成（Event-based Integration，EBI）
該風格不是直接調用另一個組件，而是一個組件能夠發布（或廣播）一個或者多個事件。在事件發布后，系統中的其他組件能夠注冊對於某些事件類型的興趣，由系統本身來調用所有已注冊的組件。
C2
C2 架構風格直接支持大粒度的重用，並且通過加強底層獨立性，支持系統組件的靈活組合。它通過將基於事件的集成風格和分層-客戶-服務器風格相結合來達到這些目標。
異步通知消息向下傳送，異步請求消息向上傳送，這是組件之間通信的唯一方式。這加強了對高層依賴的松散耦合（服務請求可以被忽略），並且與底層實現了零耦合（不知道使用了通知），從而改善了對於整個系統的控制，又沒有喪失EBI 的大多數優點。
分布式對象（Distributed Objects，DO）
該風格將系統組織為結對進行交互的組件的集合。一個對象是一個實體，這個實體封裝了一些私有的狀態信息或數據、操作數據的一組相關的操作或過程、以及一個可能存在的控制線程，這種封裝使得它們能夠被整體地看作單個的單元。
通常，一個對象的狀態對於所有其他對象而言，是完全隱藏和受到保護的。檢查或修改對象狀態的唯一方法是對該對象的一個公共的、可訪問的操作發起請求或調用。
這樣就為每個對象創建了一個良好定義的接口，在對象的操作實現和它的狀態信息保持私有的同時，公開操作對象的規格，這樣做改善了可進化性。
被代理的分布式對象（Brokered Distributed Objects，BDO）
該風格引入了名稱解析組件——其目的是將該組件接收到的客戶端請求中一個通用的服務名稱解析為一個能夠滿足該請求的對象的特定名稱，並使用這個特定名稱來答復客戶端。
為了降低對象標識的影響，現代分布式對象系統通常使用一種或更多種中間風格（intermediary styles）來輔助通信。這包括基於事件的集成風格和被代理的客戶/服務器（brokered client/server）風格。
被代理的分布式對象風格引入了名稱解析組件——其目的是將該組件接收到的客戶端請求中一個通用的服務名稱解析為一個能夠滿足該請求的對象的特定名稱，並使用這個特定名稱來答復客戶端。
盡管它改善了可重用性和可進化性，但額外的間接層要求額外的網絡交互，這降低了效率和用戶可覺察的性能。
知識點補充C2:
C2體系結構風格可以概括為：通過連接件綁定在一起的按照一組規則運作的並行構件網絡。C2風格中的系統組織規則如下：
(1)系統中的構件和連接件都有一個頂部和一個底部；
(2)構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；
(3)一個連接件可以和任意數目的其它構件和連接件連接；
(4)當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。
C2風格的體系結構
C2風格是最常用的一種軟件體系結構風格。從C2風格的組織規則和結構圖中可以得知C2風格具有以下特點：
(1)系統中的構件可實現應用需求，並能將任意復雜度的功能封裝在一起；
(2)所有構件之間的通訊是通過以連接件為中介的異步消息交換機制來實現的；
(3)構件相對獨立，構件之間依賴性較少。系統中不存在某些構件將在同一地址空間內執行，或某些構件共享特定控制線程之類的相關性假設。
REST架構風格
REST是Web自身的架構風格。REST也是Web之所以取得成功的技術架構方面因素的總結。REST是世界上最成功的分布式應用架構風格（成功案例：Web）。
它是為“運行在互聯網環境”的“分布式”“超媒體”系統量身定制的。互聯網環境與企業內網環境有非常大的差別，最主要的差別是兩個方面：
-
可伸縮性需求無法控制：並發訪問量可能會暴漲，也可能會暴跌。
-
安全性需求無法控制：無法控制客戶端發來的請求的格式，很可能會是惡意的請求。
而所謂的“超媒體系統”，即，使用了超文本的系統。可以把“超媒體”理解為超文本+媒體內容。
REST是HTTP/1.1協議等Web規范的設計指導原則，HTTP/1.1協議正是為實現REST風格的架構而設計的。新的Web規范，其設計必須符合REST的要求，否則整個Web的體系架構會因為引入嚴重矛盾而崩潰。
REST是所有Web應用都應該遵守的架構設計指導原則。
表述性狀態轉移（REST）風格是對分布式超媒體系統中的架構元素的一種抽象。
REST忽略了組件實現和協議語法的細節，以便聚焦於以下幾個方面：
- 組件的角色
- 組件之間的交互之上的約束
- 組件對重要數據元素的解釋
REST包括了一組對於定義 Web 架構基礎的組 件、連接器和數據的基本約束，因此它代表了基於網絡的應用的行為的本質。
REST提供了一組架構約束，當作為一個整體來應用時，強調組件交互的可伸縮性、接口的通用性、 組件的獨立部署、以及用來減少交互延遲、增強安全性、封裝遺留系統的中間組件。
REST架構風格最重要的架構約束有6個：
-
客戶-服務器（Client-Server）
通信只能由客戶端單方面發起，表現為請求-響應的形式。
-
無狀態（Stateless）
通信的會話狀態（Session State）應該全部由客戶端負責維護。
-
緩存（Cache）
響應內容可以在通信鏈的某處被緩存，以改善網絡效率。
-
統一接口（Uniform Interface）
通信鏈的組件之間通過統一的接口相互通信，以提高交互的可見性。
-
分層系統（Layered System）
通過限制組件的行為（即，每個組件只能“看到”與其交互的緊鄰層），將架構分解為若干等級的層。
-
按需代碼（Code-On-Demand，可選）
支持通過下載並執行一些代碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進行擴展。
REST的架構元素。
1.數據元素（Data Elements）
1.1資源和資源標識符（Resources and Resource Identifiers）
REST對於信息的核心抽象是資源。資源是一種看待服務器的方式，即，將服務器看作是由很多離散的資源組成。
它不僅僅能代表服務器文件系統中的一個文件、數據庫中的一張表等等具體的東西，可以將資源設計的要多抽象有多抽象，只要想象力允許而且客戶端應用開發者能夠理解。
與面向對象設計類似，資源是以名詞為核心來組織的，首先關注的是名詞。一個資源可以由一個或多個URI來標識。
URI既是資源的名稱，也是資源在Web上的地址。對某個資源感興趣的客戶端應用，可以通過資源的URI與其進行交互。
REST使用一個資源標識符來標識組件之間交互所涉及到的特定資源。
1.2表述（Representations）
REST組件通過以下方式在一個資源上執行動作：使用一個表述來捕獲資源的當前的或預期的狀態、在組件之間傳遞該表述。一個表述是一個字節序列，以及描述這些字節的表述元數據。
表述的其他常用但不夠精確的名稱包括：文檔、文件、HTTP 消息實體、實例或變量。表述的數據格式被稱為一種媒體類型。源的表述可以有多種格式，例如HTML/XML/JSON/純文本/圖片/視頻/音頻等等。
資源的表述格式可以通過協商機制來確定。請求-響應方向的表述通常使用不同的格式。
2.連接器（Connectors）
REST使用多種不同的連接器類型來對訪問資源和轉移資源表述的活動進行封裝。連接器代表了一個組件通信的抽象接口，通過提供清晰的關注點分離、 並且隱藏資源的底層實現和通信機制，從而改善了架構的簡單性。接口的通用性也使得組件 的可替換性成為了可能：如果用戶對系統的訪問僅僅是通過一個抽象的接口，那么接口的實現就能夠被替換，而不會對用戶產生影響。由於組件的網絡通信是由一個連接器來管理的，所以在多個交互之間能夠共享信息，以便提高效率和響應能力。
3.組件（Components）
REST 組件根據它們在整個的應用動作中的角色來進行分類。
REST的5個關鍵詞與6個主要特征
5個關鍵詞
-
資源（Resource）
-
資源的表述（Representation）
-
狀態轉移（State Transfer）
-
統一接口（Uniform Interface）
-
超文本驅動（Hypertext Driven）
資源和資源的表述上一節已經補充
狀態轉移
狀態轉移（state transfer）與狀態機中的狀態遷移（state transition）的含義是不同的。狀態轉移說的是：在客戶端和服務器端之間轉移（transfer）代表資源狀態的表述。通過轉移和操作資源的表述，來間接實現操作資源的目的。
統一接口
REST要求，必須通過統一的接口來對資源執行各種操作。對於每個資源只能執行一組有限的操作。以HTTP/1.1協議為例，HTTP/1.1協議定義了一個操作資源的統一接口，主要包括以下內容：
-
7個HTTP方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS
-
HTTP頭信息（可自定義）
-
HTTP響應狀態代碼（可自定義）
-
一套標准的內容協商機制
-
一套標准的緩存機制
-
一套標准的客戶端身份認證機制
REST還要求，對於資源執行的操作，其操作語義必須由HTTP消息體之前的部分完全表達，不能將操作語義封裝在HTTP消息體內部。這樣做是為了提高交互的可見性，以便於通信鏈的中間組件實現緩存、安全審計等等功能。
超文本驅動
“超文本驅動”又名“將超媒體作為應用狀態的引擎”（Hypermedia As The Engine Of Application State，來自Fielding博士論文中的一句話，縮寫為HATEOAS）。
將Web應用看作是一個由很多狀態（應用狀態）組成的有限狀態機。資源之間通過超鏈接相互關聯，超鏈接既代表資源之間的關系，也代表可執行的狀態遷移。
在超媒體之中不僅僅包含數據，還包含了狀態遷移的語義。以超媒體作為引擎，驅動Web應用的狀態遷移。通過超媒體暴露出服務器所提供的資源，服務器提供了哪些資源是在運行時通過解析超媒體發現的，而不是事先定義的。
從面向服務的角度看，超媒體定義了服務器所提供服務的協議。客戶端應該依賴的是超媒體的狀態遷移語義，而不應該對於是否存在某個URI或URI的某種特殊構造方式作出假設。一切都有可能變化，只有超媒體的狀態遷移語義能夠長期保持穩定。
6個主要特征：
-
面向資源（Resource Oriented）
-
可尋址（Addressability）
-
連通性（Connectedness）
-
無狀態（Statelessness）
-
統一接口（Uniform Interface）
-
超文本驅動（Hypertext Driven）
這6個特征是REST架構設計優秀程度的判斷標准。
其中，面向資源是REST最明顯的特征，即，REST架構設計是以資源抽象為核心展開的。可尋址說的是：每一個資源在Web之上都有自己的地址。
連通性說的是：應該盡量避免設計孤立的資源，除了設計資源本身，還需要設計資源之間的關聯關系，並且通過超鏈接將資源關聯起來。
無狀態、統一接口是REST的兩種架構約束，超文本驅動是REST的一個關鍵詞已經解釋。
三種架構風格的比較
- 分布式對象（Distributed Objects，簡稱DO）
架構實例有CORBA/RMI/EJB/DCOM/.NET Remoting等等。
-
遠程過程調用（Remote Procedure Call，簡稱RPC）
架構實例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等。
-
表述性狀態轉移（Representational State Transfer，簡稱REST）
架構實例有HTTP/WebDAV。
DO和RPC這兩種架構風格在企業應用中非常普遍，而REST則是Web應用的架構風格，它們之間有非常大的差別。
REST與DO的差別在於：
-
-
REST支持抽象（即建模）的工具是資源，DO支持抽象的工具是對象。在不同的編程語言中，對象的定義有很大差別，所以DO風格的架構通常都是與某種編程語言綁定的。跨語言交互即使能實現，實現起來也會非常復雜。而REST中的資源，則完全中立於開發平台和編程語言，可以使用任何編程語言來實現。
-
DO中沒有統一接口的概念。不同的API，接口設計風格可以完全不同。DO也不支持操作語義對於中間組件的可見性。
-
DO中沒有使用超文本，響應的內容中只包含對象本身。REST使用了超文本，可以實現更大粒度的交互，交互的效率比DO更高。
-
REST支持數據流和管道，DO不支持數據流和管道。
-
DO風格通常會帶來客戶端與服務器端的緊耦合。在三種架構風格之中，DO風格的耦合度是最大的，而REST的風格耦合度是最小的。REST松耦合的源泉來自於統一接口+超文本驅動。
-
REST與RPC的差別在於：
-
-
REST支持抽象的工具是資源，RPC支持抽象的工具是過程。REST風格的架構建模是以名詞為核心的，RPC風格的架構建模是以動詞為核心的。簡單類比一下，REST是面向對象編程，RPC則是面向過程編程。
-
RPC中沒有統一接口的概念。不同的API，接口設計風格可以完全不同。RPC也不支持操作語義對於中間組件的可見性。
-
RPC中沒有使用超文本，響應的內容中只包含消息本身。REST使用了超文本，可以實現更大粒度的交互，交互的效率比RPC更高。
-
REST支持數據流和管道，RPC不支持數據流和管道。
-
因為使用了平台中立的消息，RPC風格的耦合度比DO風格要小一些，但是RPC風格也常常會帶來客戶端與服務器端的緊耦合。支持統一接口+超文本驅動的REST風格，可以達到最小的耦合度。
-
比較了三種架構風格之間的差別之后，從面向實用的角度來看，REST架構風格可以為Web開發者帶來三方面的利益：
-
簡單性
采用REST架構風格，對於開發、測試、運維人員來說，都會更簡單。可以充分利用大量HTTP服務器端和客戶端開發庫、Web功能測試/性能測試工具、HTTP緩存、HTTP代理服務器、防火牆。這些開發庫和基礎設施早已成為了日常用品，不需要什么火箭科技（例如神奇昂貴的應用服務器、中間件）就能解決大多數可伸縮性方面的問題。
-
可伸縮性
充分利用好通信鏈各個位置的HTTP緩存組件，可以帶來更好的可伸縮性。其實很多時候，在Web前端做性能優化，產生的效果不亞於僅僅在服務器端做性能優化，但是HTTP協議層面的緩存常常被一些資深的架構師完全忽略掉。
-
松耦合
統一接口+超文本驅動，帶來了最大限度的松耦合。允許服務器端和客戶端程序在很大范圍內，相對獨立地進化。對於設計面向企業內網的API來說，松耦合並不是一個很重要的設計關注點。但是對於設計面向互聯網的API來說，松耦合變成了一個必選項，不僅在設計時應該關注，而且應該放在最優先位置。
但是評價一種軟件架構的優劣，不能脫離開軟件的具體運行環境。永遠不存在適用於任何運行環境的、包治百病的萬能架構。REST是一種為運行在互聯網環境中的Web應用而量身定制的架構風格。