在 微服务架构(MicroService Architecture) 一篇中,我们提到在微服务的服务之间是通过轻量级的API来实现服务之间的通信和交互。 RESTful API架构经常会用于这种服务之间的通信,本文主要来讨论一下 RESTful 架构。
REST 全称是 Representational State Transfer,中文意思是表现层状态转移。 指的是一组架构约束条件和原则。” 如果一个架构符合 REST 的约束条件和原则,我们就称它为 RESTful 架构。简单的来说: 就是用URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。
一、REST的由来
全称:REST,全称是Resource Representational State Transfer,即:资源在网络中以某种形式进行状态转移。————所谓状态的转移,可参考《HTTP权威指南》一书中对协议的详细解释,此处不过多赘述!
出现:REST最早是由Roy Fielding博士发表的论文中提到的,他也曾参与设计了HTTP协议。论文地址
定义:简单来说REST是一种系统架构设计风格(而非标准),一种分布式系统的应用层解决方案。
背景:早期的网页端是前后台一起的,比如PHP、JSP等。而随着近几年移动端的快速发展和分布式架构的应用,各种Client层出不穷,这个时候就需要有个统一的机制,来为前后端通信提供服务。而RESTful API就是目前比较成熟的的一套应用程序API设计理论。
目的:Client和Server端进一步解耦。
应用:最为经典的莫过于github API。
二、什么是状态表述转移
在 REST 的世界中,资源(Resource)即状态,每个资源都使用URI(Universal Resource Identifier)得到一个唯一的地址.
而互联网就是一个巨大的状态机;每个网页是其一个状态;URL是状态的表述;REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程。
早期互联网只有静态页面的时候,通过超链接在静态网页间浏览跳转的page->lint->page->link…模式就是一种典型的状态转移过程。
三、无状态(Stateless)服务器
REST 风格应用可以实现交互,但它却天然地具有服务器无状态的特征。客户端和服务器之间的交互在请求之间是无状态的,在状态转移的过程中,服务器不需要记录任何Session, 所有的状态都通过URL的形式记录在了客户端。
四、REST 架构风格约束
- 客户-服务器(Client-Server)通信只能由客户端单方面发起,表现为请求-响应的形式。
- 无状态(Stateless)通信的会话状态(Session State)应该全部由客户端负责维护。
- 缓存(Cache)响应内容可以在通信链的某处被缓存,以改善网络效率。
- 统一接口(Uniform Interface)通信链的组件之间通过统一的接口相互通信,以提高交互的可见性。
- 分层系统(Layered System)通过限制组件的行为(即,每个组件只能“看到”与其交互的紧邻层),将架构分解为若干等级的层。
文字比较学院派,仔细一想,想必也发现我们实际工作都已经遵守这五条架构风格了。
五、总结
引用别人的一句话简单的概括REST是干啥的:就是用URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。