其實HTTP 1.1協議的整體軟體架構就可以說是REST架構

瞭解REST得知道5個名字：

1、資源 Resource

資源就是伺服器上獲取到的東西都可以說是資源，一條使用者記錄，一個使用者的密碼，一張圖片等等都是

2、資源的表述 Representation

就是資源的格式，是HTML、XML、JSON、純文字、圖片等等，可以用各種各樣的格式來表述你獲取到的資源，這就是資源的表述

3、狀態轉移 State Transfer

URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。操作是動詞，資源是名詞

4、統一介面 Uniform Interface

REST必須通過統一的介面對資源進行操作，HTTP1.1協議定義了資源的統一介面：

·GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

`HTTP  HEAD可以自定義

·HTTP STATUS響應狀態 可自定義

·一套標準的內容協商機制

·一套標準的快取機制

·一套標準的客戶端身份認證機制

5、超文字驅動 Hypertext Driven

資源之間通過超連結相互關聯，超連結代表資源之間的關係，也代表可執行的狀態遷移

Restful API就是按照REST架構的思想設計出來的API

核心就是：將API拆分為邏輯上的資源，這些資源通過http（GET/POST/PUT/DELETE等）被操作

SpringMVC的 Restful API

這裡就是個簡單的例子，URL中tests表示資源，使用GET方法操作，得到資源物件，這裡除了GET以外的HTTP方法是404的結果

從以上例項想想，其實挺合理的，這麼豐富的HTTP方法，我們幹嘛還通過我們的自定義url來定義各種操作呢！！

有人說Restful API最好做到Hypermedia，超媒體，即返回結果提供連結，對應下一步的API，即使使用者不查文件，也知道下一步該做什麼，不過個人覺得，不是剛需，或者我還沒遇到這種需求。github就是這樣的

上面的例項是最基本的API設計了，有個很明顯的缺陷，就是API升級時會遇到問題，因為沒有版本的概念，導致服務端升級的話，所有使用的人都受到影響，但是往往實際中，有些使用者可能對新版本的API不太需要，仍然想沿用舊的，那麼唯一的辦法就是部署兩套服務端，一箇舊的，一個新的，顯然成本太高了。

所以需要在API中引入版本的概念

將版本號作為API的URL中的一個資源來設計

將來如果升級版本了，你可以通過在程式碼中新增一個else分支即可，原本的版本號的API該怎樣繼續保持不動，新的版本的邏輯新增程式碼即可，這樣可以繼續支援舊版本，將來可以通過監控來檢測舊版本的使用率，做到平滑過渡，慢慢廢棄舊版本。