### **RESTFUL ：表現層狀態轉移** rest是一組架構約束條件和原則，如果一個框架符合rest的約束條件和原則，則可以稱是一種restful架構風格。 #### **1、采用URI標識資源** 每一個資源都有一個唯一標識URI。URI既可以看成是資源的地址，也可以看成是資源的名稱。如果某些信息沒有使用URI來表示，那它就不能算是一個資源， 只能算是資源的一些信息而已。URI的設計應該遵循可尋址性原則，具有自描述性，需要在形式上給人以直覺上的關聯。 URI設計技巧： * 使用_或-來讓URI可讀性更好 * 使用/來表示資源的層級關系 * 使用?用來過濾資源 URI實例：https://github.com/git/git/pulls?state=closed #### **2、統一的REST接口規范** RESTful架構應該遵循統一接口原則，統一接口包含了一組受限的預定義的操作，不論什么樣的資源，都是通過使用相同的接口進行資源的訪問。接口應該使用標準的HTTP方法如GET，PUT和POST，并遵循這些方法的語義。 如果按照HTTP方法的語義來暴露資源，那么接口將會擁有安全性和冪等性的特性，例如GET和HEAD請求都是安全的， 無論請求多少次，都不會改變服務器狀態。而GET、HEAD、PUT和DELETE請求都是冪等的，無論對資源操作多少次， 結果總是一樣的，后面的請求并不會產生比第一次更多的影響。 * GET（SELECT）： 從服務器檢索特定資源，或資源列表。 * POST（CREATE）：在服務器上創建一個新的資源。 * PUT（UPDATE）： 更新服務器上的資源，提供整個資源。 * PATCH（UPDATE）：更新服務器上的資源，僅提供更改的屬性。 * DELETE（DELETE）：從服務器刪除資源。 統一資源接口要求使用標準的HTTP方法對資源進行操作，所以URI只應該來表示資源的名稱，而不應該包括資源的操作。 在RESTFUL架構中，每個網址代表一種資源（resource），所以網址中不能有動詞，只能有名詞，而且所用的名詞往往與數據庫的表格名對應。一般來說，數據庫中的表都是同種記錄的"集合"（collection），所以API中的名詞也應該使用復數。 #### **3、資源的表述** 客戶端通過HTTP方法可以獲取資源，準確來說，客戶端獲取的只是資源的表述而已。 資源在外界的具體呈現，可以有多種表述(或成為表現、表示)形式，在客戶端和服務端之間傳送的也是資源的表述，而不是資源本身。 例如文本資源可以采用html、xml、json等格式，圖片可以使用PNG或JPG展現出來。 資源的表述包括數據和描述數據的元數據，例如，HTTP頭"Content-Type" 就是這樣一個元數據屬性。 那么客戶端如何知道服務端提供哪種表述形式呢? 答案是可以通過HTTP內容協商，客戶端可以通過Accept頭請求一種特定格式的表述，服務端則通過Content-Type告訴客戶端資源的表述形式。 #### **4、無狀態性** RESTFUL只要維護資源的狀態，而不需要維護客戶端的狀態。對于它來說，每次請求都是全新的，它只需要針對本次請求作相應的操作，不需要將本次請求的相關信息記錄下來以便用于后續來自相同客戶端請求的處理。即所有的資源都可以URI定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而變化 ***** ### **在thinkphp中的應用：** #### **1、資源控制器** 資源控制器可以讓你輕松的創建RESTFUL資源控制器，可以通過命令行生成需要的資源控制器 ``` // 生成index模塊的Blog資源控制器 php think make:controller index/Blog 或者 php think make:controller app\index\controller\Blog ``` #### **2、注冊路由** thinkPHP5.0支持設置RESTFUL請求的資源路由，方式如下： ``` Route::resource('blog','index/Bog'); ``` 設置后會自動注冊7個路由規則，如下： |請求類型 | 路由規則 |對應方法| |---|---|---| | GET | blog |index| | GET | blog/create |create| | POST | blog |save| | GET | blog/:id |read| | GET | blog/:id/edit |edit| | PUT| blog/:id |update| | DELETE| blog/:id |delete|