8.1 遠程API方式
在構建客戶端-服務器架構時，所有程序員都會犯同樣的錯誤。他們開始將對服務器的請求視為方法調用。
您想在服務器上啟動報告生成過程，為什麼不向它發送如下請求：
http://server.com/startDocumentGeneration?params報告完成後如何下載？為此，我們將編寫另一個方法：
http://server.com/getDocument服務器中HttpSession存儲了我們文檔的信息，一旦文檔生成，服務器就會將其返回。
很棒的方法。或不？
這種做法真的很糟糕。問題是服務器必須記住文檔編號。換句話說，為了正確處理新的方法調用，服務器必須記住調用以前方法的結果。
在網絡上，這是一個大問題。互聯網可能消失，瀏覽器可能關閉。頁面可能會被重新加載或不小心點擊鏈接等。服務器將繼續存儲以前用戶請求的數兆字節數據......
為了舒適地使用服務器，您不能指望手頭總是有以前向服務器發出的請求的數據。
那麼如何調用服務器的方法呢？正確答案將是可怕的：不可能！
8.2 REST 方法
程序員回到基礎並記住最初請求包含服務器上文件的路徑：
http://server.com/path?params我們決定最大限度地使用這種方法。
現在，服務器被視為以樹的形式對外部可見的數據存儲庫。
如果要獲取所有用戶的列表，請調用查詢：
http://server.com/users如果要獲取用戶 113 的數據，請運行查詢：
http://server.com/users/113依此類推，都是一脈相承。
再一次，服務器被視為一個數據存儲庫，以樹的形式對外部可見。
可以接收數據-GET請求、修改-POST請求和刪除-DELETE請求。
8.3 無狀態
客戶端和服務器之間交互的 REST 協議需要滿足以下條件：在客戶端請求之間的時間段內，服務器上沒有存儲有關客戶端狀態的信息。
來自客戶端的所有請求都必須以這樣一種方式精心設計，即服務器每次都能收到完成請求所需的所有信息。會話狀態保存在客戶端。
在處理客戶端請求期間，客戶端被認為處於過渡狀態。每個單獨的應用程序狀態都由可以在下次客戶端點擊時調用的鏈接表示。
8.4 接口統一性
用於從服務器檢索對象的所有路徑都是標準化的。這非常方便，尤其是當您從其他 REST 服務器獲取數據時。
所有的對象接口都必須符合三個條件：
資源識別
所有資源都在使用 URI 的請求中標識。服務器內部的資源與返回給客戶端的視圖是分開的。例如，服務器可能以 HTML、XML 或 JSON 格式從數據庫發送數據，這兩種格式都不是服務器內的存儲類型。
通過視圖操作資源
如果客戶端存儲了資源的表示，包括元數據，那麼它就有足夠的信息來修改或刪除服務器上的資源。
“自我描述”消息
每條消息都包含足夠的信息以了解如何處理它。比如你需要用戶的信息，那麼服務器會返回給你一個JSON對象，裡面會有name，address字段。
不應該出現客戶端需要知道響應中的第一個數字是年齡，第二個是出生日期的情況。
8.5 緩存
REST 方法假定數據請求是通過 HTTP 協議發出的。因此，通過調用 GET 請求獲取對象。這意味著它們與通過 GET 請求接收的所有資源一樣，受緩存 HTTP 資源的所有規則約束。
也就是說，通過 REST API 接收的數據以與 Web 服務器上的任何靜態資源相同的方式緩存。美麗 ：）