REST不是英文上的rest單詞，其英文縮寫為presentational State Transfer ，直譯為表現狀態轉移，咋看起來很學術，不懂，其實不用去死摳這個詞的意思。REST是一種約束和架構（設計），符合這個風格的都算API。如果實在想了解REST ，直接看提出REST的那篇論文。
知乎上有句話總結的很好了，URL定位資源用HTTP動詞（GET POST DELETE）描述操作。
其實只要理解以下幾個原則就可以了：
1.提供資源定位
一般在計算機系統中，client和server通信交換信息，發出Action來完成任務。假設在一個to-do-list的Web應用中，客戶需要添加或者修改to-do-list，如果用非
REST的方法是這樣的：
www/changeTodoList.php?item=35&action=changeTitle&title=new_title
以上的URL是向Web API發出修改的指令，之后跟着的是一些修改的參數。但是，changeTodoList.php表述的不是一個事物，也不是一個資源（resource）,在REST的架構風格中，服務器只提供資源（only offer resources）, 資源表述的是C/S通信中的概念（即名詞）。以下就是REST的方式：
www/todolists/7/items/35/
以上的URL在語義上表現就不是一些系列命令了，只僅僅是資源的URL地址。
2.只交換自描述（self-descriptive）的消息
考慮以下場景：
/search-results?q=todo
/search-results?page=2
/search-results?page=3
以上的Web API，第一個代表搜索todo的結果，第二行todo結果的第二頁，之后類推。但是單獨從第二行的參數就無法看出這API是干嘛的，什么的第二頁？不得而知。
以下是RESTful的設計：
/search-results?q=to-do
/search-results?q=todo&page=2
/search-results?q=todo&page=3
這樣單獨每行都能解釋自身的意思，也就是自圓其說了。
3.通過連接（Links）鏈接資源（resources）
假設App向server端請求你的to-do-list：
/todolists/7/
{
"name": "My to-dos",
"items": [35, 36]
}
返回了以上的json串，item號數為35，36，但是App開發者應該從哪里通過item號來獲取API呢？沒辦法，得通過提供的文檔來向相關的Item查找Web API來查。
以下是RESTful的設計：
todolists/7/
{
"name": "My to-dos",
"items": ["/todolists/7/items/35/", "/todolists/7/items/36/"]
}
上面json直接返回相關item的URL，App開發者直接就可以獲取字符串發送請求了。
只要遵循以上幾個原則，那么設計出來的API就是RESTful的。
references:
https://www.zhihu.com/question/28557115