1.RESTful说明
1.1简介
REST（Representational State Transfer 通常被翻译为“表述性状态传输”或者“表述性状态转移”）是RoyFielding提出的一个描述互联系统架构风格的名词。为什么称为REST？Web本质上由各种各样的资源组成，资源由URI 唯一标识。浏览器（或者任何其它类似于浏览器的应用程序）将展示出该资源的一种表现方式，或者一种表现状态。如果用户在该页面中定向到指向其它资源的链接，则将访问该资源，并表现出它的状态。这意味着客户端应用程序随着每个资源表现状态的不同而发生状态转移，也即所谓 REST。
    简单地来说REST它是一种使用URL来定位资源，使用HTTP请求描述操作的Web服务规范。REST主要包括以下几方面：
    （1）    REST是一组架构约束条件和原则，而满足这些约束条件和原则的应用程序就是RESTful。   
    （2）REST的目标是构建可扩展的Web Service，它是一种更简单的SOAP(Simple Object
Access Protocol)协议以及以WSDL为基础的WebService的替代。   
    （3）REST采用的是HTTP协议并通过HTTP中的GET、POST、PUT、DELETE等动词收发数据。   
    （4）    REST希望通过HTTP来完成对数据的元操作，即传统的CRUD(Create、Read、Update、Delete)分别对应GET、POST、PUT、DELETE，这样就统一了数据操作的接口，实现在不同平台上提供一套相同的服务。   
    （5）    REST是一种面向服务的、分布式的API设计风格。
RESTful API的开发和使用，无非是客户端向服务器发请求（request），以及服务器对客户端请求的响应（response）。所以RESTful架构风格具有统一接口的特点，即：使用不同的http方法表达不同的行为：
请求方法
方法说明
GET（SELECT）
从服务器取出资源（一项或多项）
POST（CREATE）
在服务器新建一个资源
PUT（UPDATE）
在服务器更新资源（客户端提供完整资源数据）
PATCH（UPDATE
在服务器更新资源（客户端提供需要修改的资源数据）
DELETE（DELETE）
从服务器删除资源
1.2优劣分析
在很久以前，工作时间长的同学肯定经历过使用velocity语法来编写html模板代码，也就是说我们的前端页面放在服务器端那边进行编译的，更准确的可以理解为 "前后端没有进行分离"，那么在那个时候，页面、数据及模板渲染操作都是放在服务器端进行的，但是这样做有一个很大的缺点是:    后期维护比较麻烦，前端开发人员还必须掌握velocity相关的语法。因此为了解决这个问题慢慢就出现了前后端分离的思想: 即后端负责数据接口, 前端负责数据渲染, 前端只需要请求下api接口拿到数据，然后再将数据显示出来。因此后端开发人员需要设计api接口，因此为了统一规范: 社区就出现了 RESTful API 规范，其实该规范很早就有的，只是最近慢慢流行起来，RESTful API 可以通过一套统一的接口为所有web相关提供服务，实现前后端分离。
前后端说明：
1.1前后端不分离
在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。
    这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再
适用于前端App应用，为了对接App后端还需再开发一套接口。
请求的数据交互如下图:
   
1.2前后端分离
在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控
制前端的效果。
    至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中 ，前端与后端的耦合度相对较低。在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。
对应的数据交互如下图 :
   
1.3 RESTful架构优点列表
(1)前后端分离，减少流量;
(2)安全问题集中在接口上，由于接受json格式，防止了注入型等安全问题;
(3)前端无关化，后端只负责数据处理，前端表现方式可以是任何前端语言（android，ios,html5）;
(4)前端和后端人员更加专注于各自开发，只需接口文档便可完成前后端交互，无需过多相互了解;
(5)服务器性能优化：由于前端是静态页面，通过nginx便可获取，服务器主要压力放在了接口上;
2.通用说明
2.1协议
使用http协议，如果有安全方面的担忧，或者数据异常重要可以使用https
2.2编码
统一使用utf8编码
2.3域名
使用独立的api二级域名：
api.host
如果已经存在二级域名，建议使用name-api.host的形式
2.4版本控制
所有的版本号都放入url，并且使用标准版本号格式，前面加小写的v：
api.host/v1
版本号格式说明：通用的为主版本号.次版本号.修订版本号；当然，可以根据自己实际需求调整，针对某些小型项目，直接主版本号，不包含次版本号和修订版本号。版本号从v1开
始。
3.RESTful设计原则
3.1总则
1. 每一个URI代表一种资源;
2. 同一种资源有多种表现形式(xml/json);
3. 所有的操作都是无状态的。
4. 规范统一接口。
5. 返回一致的数据格式。
6. 可缓存(客户端可以缓存响应的内容)。
web后端是指什么3.2规范细则
3.2.1 URI规范
1) uri末尾不需要出现斜杠/
2) 在uri中使用斜杠/是表达层级关系的。
3) 在uri中可以使用连接符-, 来提升可读性。
比如 xxx/xx-yy 比 xxx/xx_yy中的可读性更好。
4) 在uri中不允许出现下划线字符_.
5) 在uri中尽量使用小写字符。
6) 在uri中不允许出现文件扩展名. 比如接口为 /xxx/api, 不要写成 /xxx/api.php 这样的是不合法的。
7) 在uri中使用复数形式。
在RESTful架构中，每个uri代表一种资源，因此uri设计中不能使用动词，只能使用名词，并且名词中也应该尽量使用复数形式。使用者应该使用相应的http动词 GET、POST、PUT、PATCH、DELETE等操作这些资源即可。
那么在我们未使用RESTful规范之前，我们是如下方式来定义接口的，形式是不固定的，并且没有统一的规范。比如如下形式:
xxx/api/getallUsers; // GET请求方式，获取所有的用户信息
xxx/api/getuser/1;  // GET请求方式，获取标识为1的用户信息
xxx/api/user/delete/1 // GET、POST 删除标识为1的用户信息
xxx/api/updateUser/1  // POST请求方式 更新标识为1的用户信息
xxx/api/User/add      // POST请求方式，添加新的用户

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。