維基定義：
REST，Representational State Transfer (REST) is a software architecture style consisting of guidelines and best practices for creating scalable web services. REST is a coordinated set of constraints applied to the design of components in a distributed hypermedia system that can lead to a more performant and maintainable architecture.
從上面的定義中，可以發現REST其實是一種組織Web服務的架構，而並不是實現Web服務的一種新的技術，更沒有要求一定要使用HTTP。其目標是為了創建具有良好擴展性的分布式系統。
接口就是用URL定位資源，用HTTP動詞（GET,POST,DELETE,PUT）描述操作。前后台通信方式，表現層狀態轉移。特別是基於HTTP的REST服務。
REST示例
簡單的基於HTTP的REST服務示例
假設用戶正在訪問一個電子商務網站www.jd..com。該網站對其所銷售的各個物品進行了詳細分類。當用戶登錄該網站進行購物時，首先需要在該網站上選擇其所需要尋找物品的分類，進而列出屬於該分類的各個物品。
當然，雖然從業務邏輯的角度來說這個流程非常簡單，但實際上瀏覽器向后台發送了多個請求：頁面邏輯在頁面加載時將首先得到所有的商品分類，並將這些分類顯示在了頁面中。在用戶選擇了一個分類的時候，頁面邏輯將發送一個請求得到該分類的詳細信息，並發送另外一個請求來得到該分類的商品列表：
REST系統所需要具有的HATEOAS（Hypermedia As The Engine Of Application State）特性。REST在系統設計上的視角將不再把流程放在了最優先的位置。
在設計web接口的時候，REST主要是用於定義接口名，接口名一般是用名詞寫，不用動詞，那怎么表達“獲取”或者“刪除”或者“更新”這樣的操作呢——用請求類型來區分。
比如，有一個friends接口，對於“朋友”有增刪改查四種操作，怎么定義REST接口？
增加一個朋友，uri: generalcode.cn/v1/friends 接口類型：POST
刪除一個朋友，uri: generalcode.cn/va/friends 接口類型：DELETE
修改一個朋友，uri: generalcode.cn/va/friends 接口類型：PUT
查找朋友，uri: generalcode.cn/va/friends 接口類型：GET
上面定義的四個接口就是符合REST協議的，請注意，這幾個接口都沒有動詞，只有名詞friends，都是通過Http請求的接口類型來判斷是什么業務操作。
舉個反例：generalcode.cn/va/deleteFriends 該接口用來表示刪除朋友，這就是不符合REST協議的接口。
一般接口的返回值是JSON或者XML類型的。
用HTTP Status Code傳遞Server的狀態信息。比如最常用的 200 表示成功，500 表示Server內部錯誤，403表示Bad Request等。（反例：傳統web開發返回的狀態碼一律都是200）
那這種風格的接口有什么好處呢？前后端分離。前端拿到數據只負責展示和渲染，不對數據做任何處理。后端處理數據並以JSON格式傳輸出去，定義這樣一套統一的接口，在web，ios，android三端都可以用相同的接口。