要搞确切甚么是RESTful API,具体来说要搞确切甚么是REST。REST — REpresentational State Transfer，英文的意译是“整体表现层状况迁移”。假如看那个基本概念，估算没两个人会知道是甚么原意。那上面瞧瞧我来用句人话嘿嘿甚么是RESTful:
URL功能定位天然资源，用HTTP代词（GET,POST,PUT,DELETE)叙述操作形式。
Resource：天然资源，即统计数据。
Representational：这种表达形式，比如说用JSON，XML，JPEG等；
State Transfer：状况变动。透过HTTP代词同时实现。
因此RESTful API是REST艺术风格的API。
因此在什么情景下采用RESTful API呢？
在现今的网络应用领域的后端展现传播形式很多样。有智能手机、有智能智能手机笔记本电脑除了PC和其它的展现传播形式。因此那些后端转交到的采用者允诺标准化由两个前台来处置并回到给相同的后端的确是最科学和最中国经济的形式，RESTful API是两套协定来规范化形式多样的后端和同一前台的X310e。
RESTful API由前台也是SERVER来提供更多后端来初始化。后端初始化API向前台发动HTTP允诺，后台积极响应允诺将处置意见意见反馈给后端。也是说RESTful 是众所周知的如前所述HTTP的协定。因此RESTful API有什么样结构设计准则和规范化呢？
1，天然资源。具体来说是搞确切天然资源的基本概念。天然资源是网络上的两个实体，一段文本，一张图片或者一首歌曲。天然资源总是要透过一种载体来反应它的内容。文本可以用TXT，也可以用HTML或者XML、图片可以用JPG格式或者PNG格式，JSON是现在最常用的天然资源表达形式。
2，标准化接口。RESE用来删除天然资源，这样就标准化了统计数据操作形式的接口。
3，URI。址或识别符。一般的，每个天然资源至少有两个URI与之对应，最众所周知的URI是URL。
4，无状况。所谓无状况即所有的天然资源都可以URI功能定位，而且那个功能定位与其它天然资源无关，也不会因为其它天然资源的变动而变动。有状况和无状况的区别，举个例子说明一下：
例如要查询员工工资的步骤为第一步：登录系统。第二步：进入查询工资的页面。第三步：搜索该员工。第四步：点击姓名查看工资。这样的操作形式流程是有状况的，查询工资的每两个步骤都依赖于前两个步骤，只要前置操作形式不成功，后续操作形式就无法执行。
由一个URL与之对应可以透过HTTP中的GET方法得到天然资源，这是众所周知的RESTful艺术风格。
说了这么多，到底RESTful长甚么样子的呢？
GET:http://www.xxx.com/source/id
POST:http://www.xxx.com/friends/123表示为指定ID为123的会员新增好友。其它的操作形式类似就不举例了。
RESTful API除了其它一些规范化。
1：应该将API的版本号放入URL。
GET:http://www.xxx.com/v1/friend/123。或者将版本号放在HTTP头信息中。我个人觉得要不要版本号取决于自己开发团队的习惯和业务的需要，不是强制的。2：URL中只能有名词而不能有动词，操作形式的表达是采用HTTP的代词GET,POST,PUT,DELETEL。URL只标识天然资源的地址，既然是天然资源那是名词了。
3：假如记录数量很多，服务器不可能都将它们回到给采用者。API应该提供更多参数，过滤回到结果。?limit=10：指定回到记录的数量、?page=2&per_page=100：指定第几页，和每页的记录数。
