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