REST简化开发,其架构遵循CRUD原则,该原则告诉我们对于资源(包括网络资源)只需要四种行为:创建,获取,更新和删除就可以完成相关的操作和处理。
我们可以通过统一资源标识符(Universal Resource Identifier,URI)来识别和定位资源,并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,POST,PUT,DELETE。也就是:URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。
因此设计web接口的时候,REST主要是用于定义接口名,接口名一般是用名次写,不用动词,那怎么表达“获取”或者“删除”或者“更新”这样的操作呢——用请求类型(GET,PUT,POST,DELETE)来区分。
比如我们设计一个用户管理系统的接口,如果不使用Restful风格,接口会定义如下:
http://127.0.0.1/user/query/1 #根据用户id查询用户数据 GET请求
http://127.0.0.1/user/adduser #新增用户 Post请求
http://127.0.0.1/user/update #修改用户信息 PUT请求
http://127.0.0.1/user/delete #删除用户信息 DELETE 请求
从上面的定义接口来看貌似没有什么问题,但是仔细揣测就会发现有一些瑕疵:比如查询方法定义接口使用了query
动词,而GET
请求本身的含义也就是从服务器获取资源,带有查询的含义,如果接口里面定义又加上这样的动词显得重复,同理其他几个接口也是一样的。
而使用Rest接口定义如下:
http://127.0.0.1/user/1 #GET 根据用户id查询用户数据
http://127.0.0.1/user #POST 新增用户
http://127.0.0.1/user #PUT 修改用户信息
http://127.0.0.1/user #DELETE 删除用户信息
从上面定义的接口我们可以看出,接口名称主要指向user
资源,具体的资源操作(增删改查)由HTTP的请求类型来定义。这样接口名称显得统一整洁,就不用定义不同的接口名称。遵循这样一种风格的Reset接口就叫做Restful。
HTTP方法 | 资源操作 | 幂等 | 安全 |
---|---|---|---|
GET | SELECT | 是 | 安全 |
POST | INSERT | 否 | 否 |
PUT | UPDATE | 是 | 否 |
DELETE | DELETE | 是 | 否 |
由于REST强制所有的操作都必须是无状态的,这就没有上下文的约束,如果做分布式,集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。
前后端分离。前端拿到数据只负责展示和渲染,不对数据做任何处理。后端处理数据并以JSON格式传输出去,定义这样一套统一的接口,在web,ios,android三端都可以用相同的接口。