在最近的一次技术评审会议上,听到有同事发言说:“我们的项目采用restful风格的接口设计,开发效率更高,接口扩展性更好...”,当我听到开头第一句,我脑子里就开始冒问号:项目里的接口用到的是restful风格的设计吗?restful风格的接口是怎么提高的开发效率?或者说这位同事对restful风格是不是有什么误解?于是乎,就有了这篇文章
rest是representational state transfer的缩写,翻译成中文的意思就是网络资源表述性状态转移。直译过来的内容真的很莫名其妙,有点看不懂。简单理解就是,传统的客户端与服务端资源交互接口中有资源状态的描述,restful风格的接口只有资源描述,关于状态的描述转移了,不包含在接口里了,更详细的内容接着往下看。
restful是web服务的一种架构设计风格和开发方式,本质是是一种设计思想和理念,并不是一种新技术,也不针对某一种编程语言,这种理念是在2000年的时候被一个叫Roy Fielding 的人提出来的。但是值得注意的是,rest并没有一个明确的标准,所以才被称之为一种设计风格,而这种设计风格倾向于更加简单轻量的web服务方法设计和实现。
虽然没有非常明确的标准,但是Roy Fielding 在提出这种设计理念的时候,也确定了一组架构约束条件和原则,只要满足这些约束条件和原则的应用程序或设计就可以称之为restful风格。restful主要的设计原则如下:
1、网络上的所有事物都被抽象为资源,如一张图片、一段文本,一条数据;
2、每个资源都有一个唯一的资源标识符,如URL;
3、同一个资源具有多种表现形式,即数据格式,如xml,json等;
4、对资源的各种操作不会改变资源标识符;
5、所有的操作都是无状态的,从客户端到服务端的每个请求都必须包含请求所必需的信息;
本篇文章的主角是restful,而restful风格的设计实际是对传统接口交互的一种优化设计,那么这里简单回顾一下传统的http交互接口是如何设计的,以学生信息管理为例,传统接口通常是这样设计的:
1、查询学生信息列表,http://127.0.0.1:8080/student/queryList,请求方式为post;
2、查询学生信息详情,http://127.0.0.1:8080/student/queryDetail,请求方式为get;
3、保存学生信息,http://127.0.0.1:8080/student/add,请求方式为post;
4、更新学生信息,http://127.0.0.1:8080/student/update,请求方式为post;
5、删除学生信息,http://127.0.0.1:8080/student/del,请求方式为post;
根据restful风格的设计原则,restful风格的接口通常是从这几个方面进行设计的:
1、资源定位描述设计:
restful风格的接口的每一个URL都代表一种资源,URL中只能有名词形式,不能有动词,名词能体现出操作资源的名称,完整的URL可以描述资源本身并且可以在计算机上定位到该资源;
2、资源操作设计:
资源描述设计中用 URL 定位资源,而对资源不同的操作动作,就用不同的http请求方式来表示,http的主要请求方式有get、post、put、delete;其中get表示从服务端获取资源,如查询类操作,post表示在服务端新建资源,如增加、保存类操作,put表示更新服务端上的资源,如更新操作,delete表示从服务端删除资源,如删除类操作;
3、返回状态码设计
restful风格接口的返回值状态码的设计和http状态码的设计保持一致,常用的http状态码如下:
200 – OK – 一切正常
201 – OK – 新的资源已经成功创建
204 – OK – 资源已经成功擅长
304 – Not Modified – 客户端使用缓存数据
400 – Bad Request – 请求无效,需要附加细节解释如 "JSON无效"
401 – Unauthorized – 请求需要用户验证
403 – Forbidden – 服务器已经理解了请求,但是拒绝服务或这种请求的访问是不允许的。
404 – Not found – 没有发现该资源
422 – Unprocessable Entity – 只有服务器不能处理实体时使用,比如图像不能被格式化,或者重要字段丢失。
500 – Internal Server Error – API开发者应该避免这种错误。
rest的直译意思是网络资源表述性状态转移,转移后的状态是什么样的呢?还以学生信息管理为例,采用restful风格的设计大概是这样的:
1、查询学生信息列表,http://127.0.0.1:8080/students,请求方式为get;
2、查询学生信息详情,http://127.0.0.1:8080/student/{id},请求方式为get;
3、保存学生信息,http://127.0.0.1:8080/student,请求方式为post;
4、更新学生信息,http://127.0.0.1:8080/student,请求方式为put;
5、删除学生信息,http://127.0.0.1:8080/student,请求方式为delete;
如果是不同的客户端、版本的接口还可以这样区分:
1、查询学生信息列表,http://127.0.0.1:8080/web/v1/students,请求方式为get;
2、查询学生信息详情,http://127.0.0.1:8080/web/v1/student/{id},请求方式为get;
3、保存学生信息,http://127.0.0.1:8080/web/v1/student,请求方式为post;
4、更新学生信息,http://127.0.0.1:8080/web/v1/student,请求方式为put;
5、删除学生信息,http://127.0.0.1:8080/web/v1/student,请求方式为delete;
从上面学生信息管理的相关restful风格的接口观察,restful风格的接口大概有以下3个特征:
1、每个URL只表述资源本身;
2、不同的请求方式表述对资源的操作;
3、客户端和服务端之间,传递资源的某种资源的表现层;
@RestController
public class StudentController {
/**
* 查询学生信息列表接口
* @param param
* @return
*/
@GetMapping("/students")
public List studentList(Student param) {
List result = new ArrayList<>();
//列表查询业务逻辑
return result;
}
/**
* 查询学生详情信息接口
* @param param
* @return
*/
@GetMapping("/student")
public Student detail(Student param) {
Student student = new Student();
//详情查询业务逻辑
return student;
}
/**
* 增加学生信息接口
* @param student
* @return
*/
@PostMapping("/student")
public Student add(Student student) {
//新增学生信息业务逻辑
return student;
}
/**
* 更新学生信息接口
* @param student
* @return
*/
@PutMapping("/student")
public Student update(Student student) {
//更新学生信息业务逻辑
return student;
}
/**
* 删除学生信息接口
* @param student
* @return
*/
@DeleteMapping("/student")
public Student delete(Student student) {
//删除学生信息业务逻辑
return student;
}
}
1、URL本身有很强的可读性,具备自描述性;
2、强调http请求以资源为中心,规范了不同http请求方式的使用,具有对应的语义;
3、无状态的服务接口,可提高应用的扩展水平;
restful的理念,本质上是用一种更加简单、清晰、便捷的方式,来定位、描述网络上的资源以及对这些资源的操作。具体在实操上,可能就仁者见仁,智者见智了。回头文章的开始,实际的项目接口的请求方式基本上是以post为主,get请求极少,put和delete请求根本没有,URL的命名实际上仍是传统的方式。restful对开发效率有明显的提升吗?我觉得未必,只不过接口定义看起来更简洁了,无形中开发效率会有一点点的提升,要说明显肯定是没有。