REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。它是一種針對網絡應用的設計和開發方式，可以降低開發的複雜性，提高系統的可伸縮性。
總之rest就是一種設計風格 , 而不是一種深奧的技術!!!,滿足這些約束條件和原則的應用程序或設計就是 RESTful。
二、RESTFul API 的特點
- 基於“資源”，數據也好、服務也好，在RESTFul設計裏一切都是資源。
- 無狀態。一次調用一般就會返回結果，不存在類似於“打開連接-訪問數據-關閉連接”這種依賴於上一次調用的情況。http請求一樣
- URL中通常不出現動詞，只有名詞
- URL語義清晰、明確
- 使用HTTP的GET(獲取)、POST(創建)、DELETE(刪除)、PUT(更新)來表示對於資源的增刪改查
- 出參使用JSON不使用XML
三、RESTFul API 的實踐原則
- 使用HTTP動詞表示增刪改查資源， GET：查詢，POST：新增，PUT：更新，DELETE：刪除
- 返回結果必須使用JSON
- HTTP狀態碼，在REST中都有特定的意義：200，201,202,204,400,401,403,500。比如401表示用戶身份認證失敗，403表示你驗證身份通過了，但這個資源你不能操作。
- 如果出現錯誤，返回一個錯誤碼
四、restful風格的接口真的好嗎?
我的一個經驗性的總結：對於開放的API，豆瓣、新浪微博、GitHub，好用，非常合適；對於內部開發，不好用。
基於資源型的RESTFul API 接口粒度和返回結果過於的“粗”，它通常返回的都是完整的數據模型，這對於客戶端非常不友好。但開放API之所以開放，就是因爲它不知道你到底需要什麼返回結果，既然不知道，那麼我乾脆都返回給你。這樣的好處是通用，但客戶端不好處理。你只需要一個字段，服務器啪的丟給你十幾個，作爲客戶端開發者你怎麼想？
內部開發由於需求非常明確，通常來說服務器是不應該簡單粗暴的直接甩資源實體給客戶端的。那RESTFul API就不能接入到內部開發嗎？當然不是，我們需要靈活一些借鑑RESTFul中的優點，來設計我們的內部API。那麼如何簡化，這就不是一篇文章能夠說清楚的了，也沒有一個統一的標準，需要自己去琢磨和體會。
最後舉個例子吧，我個人在開發內部接口時會保留絕大多數的REST 特性，但我不會嚴格的只寫增、刪、改、查四個接口。必要的時候，還是要靈活處理一下。而且錯誤碼、狀態碼這些非常優秀的特性，必須保留。