转载:关于对REST的基本认识和理解
- 客戶-服務器（Client-Server）
通信只能由客戶端單方面發起，表現為請求-響應的形式。
- 無狀態（Stateless）
通信的會話狀態（Session State）應該全部由客戶端負責維護。
- 緩存（Cache）
響應內容可以在通信鏈的某處被緩存，以改善網絡效率。
- 統一接口（Uniform Interface）
通信鏈的組件之間通過統一的接口相互通信，以提高交互的可見性。
- 分層系統（Layered System）
通過限制組件的行為（即，每個組件只能“看到”與其交互的緊鄰層），將架構分解為若干等級的層。
- 按需代碼（Code-On-Demand，可選）
支持通過下載并執行一些代碼（例如Java Applet、Flash或JavaScript），對客戶端的功能進行擴展。
?
3.要深入理解REST，需要理解REST的五個關鍵詞：
什么是資源？
資源是一種看待服務器的方式，即，將服務器看作是由很多離散的資源組成。每個資源是服務器上一個可命名的抽象概念。因為資源是一個抽象的概念，所以它不僅僅能代表服務器文件系統中的一個文件、數據庫中的一張表等等具體的東西，可以將資源設計的要多抽象有多抽象，只要想象力允許而且客戶端應用開發者能夠理解。與面向對象設計類似，資源是以名詞為核心來組織的，首先關注的是名詞。一個資源可以由一個或多個URI來標識。URI既是資源的名稱，也是資源在Web上的地址。對某個資源感興趣的客戶端應用，可以通過資源的URI與其進行交互。
什么是資源的表述？
資源的表述是一段對于資源在某個特定時刻的狀態的描述。可以在客戶端-服務器端之間轉移（交換）。資源的表述可以有多種格式，例如HTML/XML/JSON/純文本/圖片/視頻/音頻等等。資源的表述格式可以通過協商機制來確定。請求-響應方向的表述通常使用不同的格式。
什么是狀態轉移？
狀態轉移（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的某種特殊構造方式作出假設。一切都有可能變化，只有超媒體的狀態遷移語義能夠長期保持穩定。
?
從架構風格的抽象高度來看，常見的分布式應用架構風格有三種：
- 分布式對象（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來說，松耦合變成了一個必選項，不僅在設計時應該關注，而且應該放在最優先位置。
轉載自：http://www.infoq.com/cn/articles/understanding-restful-style轉載于:https://www.cnblogs.com/jbml-154312/p/8275500.html
總結
以上是生活随笔為你收集整理的转载:关于对REST的基本认识和理解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mongodb在aggregate lo
- 下一篇： bootstrapselect使用 Bo