1.RESTful概念理解
1.1 通过翻译来理解REST原则。
在说RESTful架构之前,我们得先了解一下REST(Representational State Transfer)原则。搜索一下三个单词的意思
-
Representational:具体化的,反义词是抽象的
State:状态
Transfer:转换
以我大学英语四级的水平拼凑了一下,大致的意思是表现层状态转换。
这句解释是缺少主语的,提出REST原则的人则将这个主体定为我们每天都在用的网络“资源”(Resource)-资源的表现层状态转换。
1.2 REST原则定义的资源表现形式(Representational)
"资源"是一种信息实体,它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式,叫做它的"表现层"(Representation)。比如,文本可以用txt格式表现,也可以用HTML格式、XML格式、JSON格式表现,设置可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现。对于网络资源而言,有时候你会看见一些能表达资源形式的URI,例如学习jsp的新手时常以这种格式的URI来访问自己的JSP页面:localhost:端口号/项目名/xxx.jsp。然而这种情况却很少发生在正式开发的网站上,例如www.baidu.com 这个URL我清楚地知道是访问百度这张页面,但是我不知道这张页面的格式是html还是jsp,他隐瞒了资源的表现形式。REST原则认为URI应该只代表资源的实体,不代表它的形式。严格来说,有些网址最后的“.html”都是不必要的,因为这种后缀表示问价格式,属于“表现层”范畴,而URI只代表“资源”的位置。
REST原则规定所有资源的表现形式应该定义在HTTP请求中,通过HTTP请求头信息中的Accept和Content-Type字段指定。
QUESTION ONE:为何网站上大多数的图片资源的URI是直接加图片后缀的,这显然不满足REST原则,例如百度首页的图片:https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/img/logo/bd_logo1_31bdc765.png
解释:图片等是静态资源,REST原则的主体对象是动态页面。
1.3 资源表现形式转换(State Transfer)
客户端通过HTTP协议使服务器端发生“状态转换”,而HTTP协议包含了描述资源形式的内容(Accept、Content-Type等,可称为资源的表现层),即客户端基于“表现层”之上对服务端进行操作,因此称为“表现层状态转换”,这就是REST原则用来规范化的动作实体。
其中HTTP协议中规定的操作比较让人熟知的有以下几种:DELETE、PUT、GET、POST,而对于这四种操作,服务器端应该完成哪些工作呢(就是上文说的“状态转换”)?下表是一个小小的总结:
HTTP操作 | 服务器应该完成的动作 |
DELETE | 服务器会按要求删除资源
|
PUT | 服务器会去更改资源
|
GET | 服务器会去获取资源
|
POST | 服务器会去获取或更改资源
|
这里所说的资源可以是一张页面,也可以是数据库中的信息,或者一段简单的文本,甚至一段js,预期返回的资源格式由http请求中的Accept字段定义默认的Accept为*/*,表示可接受任何类型的资源,包括文本、图片等。
出于好奇,看了一下baidu.com的http请求(通过cherome),见下图:
QUESTION TWO:其实在Accept中*/*以及表示愿意接受任何格式的资源,那为何还要写“text/html,application.xhtml+xml......”这么长的一段话,由什么特殊含义?
等待各位看官解答当中。
1.4 用思维导图做一个小小的总结
综合上面的解释,我们总结一下什么是RESTful架构:
(1)每一个URI代表一种资源;
(2)客户端和服务器之间,传递这种资源的某种表现层;
(3)客户端通过四个HTTP动词,对服务器端资源进行操作,实现"表现层状态转化"。
2.RESTful架构理解
2.1 RESTful架构的定义
所有满足上述中REST原则的架构都可称为RESTful架构。(RESRful就是这样一个形容词)。
3. RESRful架构与MVC架构
3.1 二者的区别
两者实际上是不冲突的:
RESTful架构的重点在于对URI和http请求的规范化,以及要求服务器端与HTTP请求中的操作类型有相对应的返回资源;
而MVC架构的重点在于数据层、表现层、操作层之间的沟通设计。
以上便是我的对RESTful架构的个人总结,有错误欢迎指出