『壹』 如何理解rest和restful，什麼是restfulAPI
簡單理解一
就是用URL定位資源，用HTTP描述操作。
簡單理解二
URL定位資源，用HTTP動詞(GET,POST,DELETE,DETC)描述操作。
官方定義
一種軟體架構風格、設計風格，而不是標准，只是提供了一組設計原則和約束條件。它主要用於客戶端和伺服器交互類的軟體。基於這個風格設計的軟體可以更簡潔，更有層次，更易於實現緩存等機制。
以web開發舉例
在設計web介面的時候，REST主要是用於定義介面名，介面名一般是用名次寫，不用動詞，那怎麼表達「獲取」或者「刪除」或者「更新」這樣的操作呢——用請求類型來區分。
比如，我們有一個students介面，對於「學生」我們有增刪改查四種操作，怎麼定義REST介面？
增加一個學生，uri: http://testcode.com/school/students 介面類型：POST
刪除一個朋友，uri: http://testcode.com/school/students 介面類型：DELETE
修改一個朋友，uri: http://testcode.com/school/students 介面類型：PUT
查找朋友，uri: http://testcode.com/school/students 介面類型：GET
上面我們定義的四個介面就是符合REST協議的，請注意，這幾個介面都沒有動詞，只有名詞students，都是通過Http請求的介面類型來判斷是什麼業務操作。
舉個反例
uri: http://testcode.com/school/addStudents 該介面用來表示增加學生，這就是不符合REST協議的介面。
建議
用HTTP Status Code傳遞Server的狀態信息。比如最常用的 200 表示成功，500 表示Server內部錯誤，403表示Bad Request等。(反例：傳統web開發返回的狀態碼一律都是200，其實不可取。)
REST風格介面意義
前後端分離。前端拿到數據只負責展示和渲染，不對數據做任何處理。後端處理數據並以JSON格式傳輸出去，定義這樣一套統一的介面，在web，ios，android三端都可以用相同的介面，節約開發成本以及便於同一調試。
『貳』 Restful api 的資源內容應不應該帶上 ID
路徑，API的具體地址。在REST中，每個地址都代表一個具體的資源（Resource）。所以就有了以下的約定：
路徑僅表示資源的路徑（位置），以及一些特殊的actions操作。
以 復數（名詞） 進行命名資源，不管返回單個或者多個資源。
使用 小寫字母、數字以及下劃線（「_」） 。（下劃線是為了區分多個單詞，如token_access）。
資源的路徑從父到子依次如：/{resource}/{resource_id}/{sub_resource}/{sub_resource_id}/{sub_resource_property}。
使用?來進行資源的過濾、搜索以及分頁等。
使用版本號，且版本號在資源路徑之前。
優先使用內容協商來區分表述格式，而不是使用後綴來區分表述格式。
應該放在一個專用的域名下，如：http：//api.webfuse.cn。
建議使用SSL。
『叄』 restful和http的區別
REST 定義了一組體系架構原則，您可以根據這些，包括使用不同語言編寫的客戶端如何通過 HTTP 處理和傳輸資源狀態。所以在事實上，REST 對 Web的影響非常大，由於其使用相當方便，已經普遍地取代了基於 SOAP 和 WSDL 的介面設計。在多年以後的今天，REST的主要框架已經開始雨後春筍般的出現。
個人理解：
（一） 首先REST只是一種風格，不是一種標准
（二） REST是以資源為中心的
（三） REST充分利用或者說極端依賴HTTP協議
一．對於今天正在吸引如此多注意力的最純粹形式的 REST Web 服務，其具體實現應該遵循以下基本設計原則：
1.1．顯式地使用不同的 HTTP 請求方法
1.2．無狀態
1.3．公開目錄結構式的 URI(通過邏輯URI定位資源)。
1.1．顯式地使用不同的 HTTP 請求方法
我們在 Web 應用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構中，用不同的 HTTP 請求方法來處理對資源的 CRUD（創建、讀取、更新和刪除）操作：
若要在伺服器上創建資源，應該使用 POST 方法。
若要檢索某個資源，應該使用 GET 方法。
若要更改資源狀態或對其進行更新，應該使用 PUT 方法。
若要刪除某個資源，應該使用 DELETE 方法。
『肆』 什麼是REST API
REST 是REpresentational State Transfer的縮寫，字面的翻譯是表現層狀態轉移。
RESTful API就是REST風格的網路介面，REST描述的是在網路中client和server的一種交互形式；REST本身不實用，實用的是如何設計。
Server提供的RESTful API中，URL中只使用名詞來指定資源，原則上不使用動詞。「資源」是REST架構或者說整個網路處理的核心。
拓展資料:
REST指一組架構約束條件和原則，滿足約束條件和原則的應用程序設計。架構，軟體體系結構分為三部分：構建，用於描述計算機；連接器，用於描述構建的鏈接部分；配置將構建和連接器組成有機整體。
web基本技術：
URI（統一資源標示符）HTTP（超文本傳輸協議）（post、get、put、delete） Hypertext。
1、每個資源都應該有唯一的一個標識
2、使用標準的方法更改資源的狀態
3、request和response的自描述
4、資源多重表述
5、無狀態服務
用HTTP協議里的動詞來實現資源的添加，修改，刪除等操作。即通過HTTP動詞來實現資源的狀態扭轉：
GET 用來獲取資源
POST 用來新建資源（也可以用於更新資源）
PUT 用來更新資源，
DELETE 用來刪除資源。
『伍』 restful api介面規范是什麼
REST（REpresentationStateTransfer）描述了一個架構樣式的網路系統，比如web應用程序。
一般依賴於HTTP認證，HTTP認證有幾種：basic，digest，token，這些都有標準的實現的開源包需要主要的是這個認證的帳號跟你業務的帳戶實際是不一樣的。REST屬於webService一種，安全是後台服務的安全，因此不需要實際的業務帳號，通常是系統keyStore證書庫里的賬戶。
RESTFUL特點包括：
1、每一個URI代表1種資源。
2、客戶端使用GET、POST、PUT、DELETE4個表示操作方式的動詞對服務端資源進行操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
3、通過操作資源的表現形式來操作資源。
4、資源的表現形式是XML或者HTML。
5、客戶端與服務端之間的交互在請求之間是無狀態的，從客戶端到服務端的每個請求都必須包含理解請求所必需的信息。
『陸』 如何設計好的RESTful API
規劃好你的API的外觀要先於開發它實際的功能。首先你要知道數據該如何設計和核心服務/應用程序會如何工作。如果你純粹新開發一個API，這樣會比較容易一些。但如果你是往已有的項目中增加API，你可能需要提供更多的抽象。
有時候一個集合可以表達一個資料庫表，而一個資源可以表達成裡面的一行記錄，但是這並不是常態。事實上，你的API應該盡可能通過抽象來分離數據與業務邏輯。這點非常重要，只有這樣做你才不會打擊到那些擁有復雜業務的第三方開發者，否則他們是不會使用你的API的。
當然你的服務可能很多部分是不應該通過API暴露出去的。比較常見的例子就是很多API是不允許第三方來創建用戶的。
GET (選擇）：從伺服器上獲取一個具體的資源或者一個資源列表。
POST（創建）：在伺服器上創建一個新的資源。
PUT（更新）：以整體的方式更新伺服器上的一個資源。
PATCH（更新）：只更新伺服器上一個資源的一個屬性。
DELETE（刪除）：刪除伺服器上的一個資源。
還有兩個不常用的HTTP動詞：
HEAD：獲取一個資源的元數據，如數據的哈希值或最後的更新時間。
OPTIONS：獲取客戶端能對資源做什麼操作的信息。
一個好的RESTful API只允許第三方調用者使用這四個半HTTP動詞進行數據交互，並且在URL段裡面不出現任何其他的動詞。
一般來說，GET請求可以被瀏覽器緩存（通常也是這樣的）。例如，緩存請求頭用於第二次用戶的POST請求。HEAD請求是基於一個無響應體的GET請求，並且也可以被緩存的。
『柒』 restful怎麼通過get方法表示一個動詞
標准沒有不允許你使用自定義頭，自定義頭可以以 `X-` 開頭，比如 `X-MyToken`如果用 OAuth 2，連自定義頭都不需要，bearer token 直接放在 `Authorization` 頭里。
『捌』 REST 架構該怎麼生動地理解
相同問題一起答了！
我覺得問題很好，我自己去年創業的時候去學習REST和嘗試著設計RESTful API，一直覺得它的文檔晦澀難懂，國內也沒有找到太好文章。後來一年內反復琢磨了好幾遍，和FB+Square的朋友討論過好幾次，有了一個比較清晰的總結。分享如下：
@Ivony 老師的一句話概括很精闢：
URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。
--- 簡潔版 ---
0. REST不是"rest"這個單詞，而是幾個單詞縮寫。但即使那幾個單詞說出來，也無法理解在說什麼 -_-!! （不是要貶低人，是我自己也理解困難）；
1. REST描述的是在網路中client和server的一種交互形式；REST本身不實用，實用的是如何設計 RESTful API（REST風格的網路介面）；
2. Server提供的RESTful API中，URL中只使用名詞來指定資源，原則上不使用動詞。「資源」是REST架構或者說整個網路處理的核心。比如：
api.qc.com/v1/newsfeed: 獲取某人的新鮮;
api.qc.com/v1/friends: 獲取某人的好友列表;
api.qc.com/v1/profile: 獲取某人的詳細信息;3. 用HTTP協議里的動詞來實現資源的添加，修改，刪除等操作。即通過HTTP動詞來實現資源的狀態扭轉：
GET 用來獲取資源，
POST 用來新建資源（也可以用於更新資源），
PUT 用來更新資源，
DELETE 用來刪除資源。
『玖』 怎樣理解restful格式中的uri
REST -- REpresentational State Transfer 直接翻譯：表現層狀態轉移。這個中文直譯經常出現在很多博客中。尼瑪誰聽得懂「表現層狀態轉移」？這是人話嗎？我自己也困惑了很久，查詢了很多資料，花了差不多一年有個還算清晰的理解。分享如下：
Ivony 老師的一句話概括很精闢：
URL定位資源，用HTTP動詞（GET,POST,DELETE,DETC）描述操作。
--- 簡潔版 ---
0. REST不是"rest"這個單詞，而是幾個單詞縮寫。但即使那幾個單詞說出來，也無法理解在說什麼 -_-!! （不是要貶低人，是我自己也理解困難）；
1. REST描述的是在網路中client和server的一種交互形式；REST本身不實用，實用的是如何設計 RESTful API（REST風格的網路介面）；
2. Server提供的RESTful API中，URL中只使用名詞來指定資源，原則上不使用動詞。「資源」是REST架構或者說整個網路處理的核心。