一句話解釋就是「通過路徑知曉訪問資源是何， 通過請求方式知道要做什麼操作」
大致遵循以下兩個規則：請求 api 的 url 表示用來定位資源；
請求的 method 表示對這個資源進行的操作；
通過url用來定位資源，跟要進行的操作區分開，這就意味著url不該有任何動詞
下面示例中的 get、create、search 等動詞，都不應該出現在 rest 架構的後端介面路徑中。比如：
/api/getuser
/api/searchresult
/api/deleteallusers
當我們需要對單個使用者進行操作時，根據操作的方式不同可能需要下面的這些介面：
/api/getuser （用來獲取某個使用者的資訊，還需要以引數方式傳入使用者 id 資訊）
/api/updateuser （用來更新使用者資訊）
/api/deleteuser （用來刪除單個使用者）
/api/resetuser （重置使用者的資訊）
可能在更新使用者不同資訊時，提供不同的介面，比如：
/api/updateusername
/api/updateuseremail
/api/updateuser
正確的定義方式應該是
以上三種情況的弊端在於：首先加上了動詞，肯定是使 url 更長了；其次對乙個資源實體進行不同的操作就是乙個不同的 url，造成 url 過多難以管理。
其實當你回過頭看「url」這個術語的定義時，更能理解這一點。url 的意思是統一資源定位符，這個術語已經清晰的表明，乙個 url 應該用來定位資源，而不應該摻入對操作行為的描述。
url 中不應該出現任何表示操作的動詞，鏈結只用於對應資源；
url 中應該單複數區分，推薦的實踐是永遠只用複數；比如get /api/users表示獲取使用者的列表；如果獲取單個資源，傳入 id，比如/api/users/123表示獲取單個使用者的資訊；
按照資源的邏輯層級，對 url 進行巢狀，比如乙個使用者屬於某個團隊，而這個團隊也是眾多團隊之一；那麼獲取這個使用者的介面可能是這樣：get /api/teams/123/members/234 表示獲取 id 為 123 的小組下，id 為234 的成員資訊。
按照類似的規則，可以寫出如下的介面
/api/teams （對應團隊列表）
/api/teams/123 （對應 id 為 123 的團隊）
/api/teams/123/members （對應 id 為 123 的團隊下的成員列表）
/api/teams/123/members/456 （對應 id 為 123 的團隊下 id 未 456 的成員）
顧名思義
【get】 用於對某一(些)資源的『獲取』
【post】 用於對某一(些)資源進行『建立』操作
【delete】 用於對某一(些)資源進行『刪除 』
【put】 用於對某一(些)資源進行『更新』
代表api的版本資訊。
代表網域名稱 （例如： localhost / 127.0.0.1）
代表這個域(domain)下，你所訪問的資源路徑(約定的rest介面)
具體示例如下：
總結幾個關鍵點，來更清晰的表述規則。
一些其他規範：
規則1：uri結尾不應包含（/）
規則2：正斜槓分隔符（/）必須用來指示層級關係
規則3：應使用連字元（ - ）來提高uri的可讀性
規則4：不得在uri中使用下劃線（_）
規則5：uri路徑中全都使用小寫字母
後端nodejs的restful介面
var express require express express 讀取body中的json請求資料，前端post請求時傳送來的json物件 var bodyparser require body parser use bodyparser.urlencoded use bodyparser.j...
RESTful （俗稱 api介面文件）
api與使用者的通訊協議，總是使用https協議，確保互動資料的傳輸安全。應該盡量將api部署在專用網域名稱之下。如果確定api很簡單，不會有進一步擴充套件，可以考慮放在主網域名稱下。應該將api的版本號放入url。v 另一種做法是，將版本號放在http頭資訊中，但不如放入url方便和直觀。gith...
RESTful風格API介面及狀態碼
1.1 什麼是restful 1.web開發本質 2.restful api設計規範 1 子網域名稱方式 盡量將api部署在專用網域名稱 會存在跨 域問題 2 url方式 api api很簡單url 如 v1 請求頭跨域時，引發傳送多次請求 v1 zoos v1 animals v1 employe...