RESTful架构个人理解

在移动互联网的大潮下,随着docker等技术的兴起,微服务的概念也越来越被大家接受并应用于实践,日益增多的web service逐渐统一于RESTful架构风格.而作为一个开发者,了解REST势在必行

REST的定义

REST的全称是Representational State Transfer,中文意思是表述性状态转移.REST是一种组织web服务的架构,其目标是创建具有良好扩展性的分布式系统.反过来,作为一种架构,它定义了用于创建web服务的一系列约束.符合REST架构的web服务允许客户端使用统一且预定义的无状态操作集来获取或操作文本表示的web资源

历史

Roy Fielding于2000年的博士论文中定义REST为”架构风格以及基于网络的软件架构的设计”.他在1996-1999年间同时开发了REST架构风格和HTTP1.1

架构属性

REST架构风格的约束使架构具有如下属性:

  1. 高效性(performance).组件之间的交互是高效的.它是用户感知性能和网络效率的主要因素
  2. 可扩展性(scalability).可扩展性允许支持大量组件以及组件之间的交互
  3. 简洁性(simplicity).一个统一的接口应该是简洁的
  4. 可见性(visibility).组件之间的通信应该是可见的
  5. 可移植性(portability).组件应该是可移植的(通过移动程序代码和数据)
  6. 可靠性(reliability).对于存在的组件,连接,数据故障,应当有系统级故障的可靠性
  7. 可修改性(modifiability).组件当需要修改时,应当是可修改的(即使程序仍在运行)

架构约束

六个指导性约束定义了一个RESTful系统.这些约束限制了服务器处理与回复客户端的请求.因此,在这些约束下运作,服务就能拥有如高效性,可扩展性,间接性等等的架构属性.而一个服务一旦忽略了任何一个所需的约束,则它不能被称为”RESTful”

如下是正式的REST约束:

  1. 客户端/服务端模型:该约束的背后原则是关注点的分离,客户端与服务端之间使用一个统一的接口来通讯
  2. 无状态:在一个REST系统中,服务端并不会保存有关客户的任何状态.也就是说,客户端自身负责用户状态的维持,并在每次发送请求时都需要提供足够的信息
  3. 可缓存:REST系统需要能够恰当地缓存请求,以尽量减少服务端和客户端之间的信息传输,以提高性能
  4. 层次化的系统:客户端通常无法它是直接连接到服务器,还是通过中介服务器(可能有负载均衡以及安全策略)
  5. 需求时代码(可选):服务器可以通过传输可执行代码来临时扩展或定制客户端的功能
  6. 统一的接口:一个REST服务中每个组件都应该有统一的接口,以便于每一部分都独自演化

    统一的接口体现为四个方面:

    • 请求中的资源标识:每个资源的资源标识可以用来唯一地标明该资源
    • 通过表示来处理资源:在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息.例如该消息所使用的MIME类型,是否可以被缓存等
    • 自我描述性的信息:每个信息都有足够的信息来描述自身,并提供足够的信息来处理自身,例如content-type
    • 超媒体作为应用程序状态的引擎:客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息,如到底是向哪个URL发送请求等

参考文档

loveis715的cnblog

REST的维基百科

推荐!!! 阮一峰:REST架构的理解

0%