什么是REST架构 - z

什么是REST架构 - z

REST架构风格是全新的针对Web应用的开发风格,是当今世界最成功的互联网超媒体分布式系统架构,它使得人们真正理解了Http协议本来面貌。随着 REST架构成为主流技术,一种全新的互联网网络应用开发的思维方式开始流行。

REST是什么

REST是英文Representational State Transfer的缩写,中文翻译为“表述性状态转移”,他是由Roy Thomas Fielding博士在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST本身只是为分布式超媒体系统设计的一种架构风格,而不是标准。

基于Web的架构,实际上就是各种规范的集合,这些规范共同组成了Web架构。比如Http协议,比如客户端服务器模式,这些都是规范。每当我们在原有规 范的基础上增加新的规范,就会形成新的架构。而REST正是这样一种架构,他结合了一系列的规范,而形成了一种新的基于Web的架构风格。

传统的Web应用大都是B/S架构,它包括了如下一些规范 。

客户-服务器

这种规范的提出,改善了用户接口跨多个平台的可移植性,并且通过简化服务器组件,改善了系统的可伸缩性。最为关键的是通过分离用户接口和数据存储这两个关注点,使得不同用户终端享受相同数据成为了可能。

无状态性

无 状态性是在客户-服务器约束的基础上添加的又一层规范。他要求通信必须在本质上是无状态的,即从客户到服务器的每个request都必须包含理解该 request所必须的所有信息。这个规范改善了系统的可见性(无状态性使得客户端和服务器端不必保存对方的详细信息,服务器只需要处理当前 request,而不必了解所有的request历史),可靠性(无状态性减少了服务器从局部错误中恢复的任务量),可伸缩性(无状态性使得服务器端可以 很容易的释放资源,因为服务器端不必在多个request中保存状态)。同时,这种规范的缺点也是显而易见得,由于不能将状态数据保存在服务器上的共享上 下文中,因此增加了在一系列request中发送重复数据的开销,严重的降低了效率。

缓存

为 了改善无状态性带来的网络的低效性,我们填加了缓存约束。缓存约束允许隐式或显式地标记一个response中的数据,这样就赋予了客户端缓存 response数据的功能,这样就可以为以后的request共用缓存的数据,部分或全部的消除一部分交互,增加了网络的效率。但是用于客户端缓存了信 息,也就同时增加了客户端与服务器数据不一致的可能,从而降低了可靠性。

B/S架构的优点是其部署非常方便,但在用户体验方面却不是很理想。为了改善这种情况,我们引入了REST。

REST在原有的架构上增加了三个新规范:统一接口,分层系统和按需代码。

统一接口

REST 架构风格的核心特征就是强调组件之间有一个统一的接口,这表现在REST世界里,网络上所有的事物都被抽象为资源,而REST就是通过通用的链接器接口对 资源进行操作。这样设计的好处是保证系统提供的服务都是解耦的,极大的简化了系统,从而改善了系统的交互性和可重用性。并且REST针对Web的常见情况 做了优化,使得REST接口被设计为可以高效的转移大粒度的超媒体数据,这也就导致了REST接口对其它的架构并不是最优的。

分层系统

分层系统规则的加入提高了各种层次之间的独立性,为整个系统的复杂性设置了边界,通过封装遗留的服务,使新的服务器免受遗留客户端的影响,这也就提高了系统的可伸缩性。

按需代码

REST允许对客户端功能进行扩展。比如,通过下载并执行applet或脚本形式的代码,来扩展客户端功能。但这在改善系统可扩展性的同时,也降低了可见性。所以它只是REST的一个可选的约束。

REST的设计准则

REST架构是针对Web应用而设计的,其目的是为了降低开发的复杂性,提高系统的可伸缩性。REST提出了如下设计准则:

网络上的所有事物都被抽象为资源(resource); 
    每个资源对应一个唯一的资源标识符(resource identifier); 
    通过通用的连接器接口(generic connector interface)对资源进行操作; 
    对资源的各种操作不会改变资源标识符; 
    所有的操作都是无状态的(stateless)。

REST中的资源所指的不是数据,而是数据和表现形式的组合,比如“最新访问的10位会员”和“最活跃的10为会员”在数据上可能有重叠或者完全相同,而 由于他们的表现形式不同,所以被归为不同的资源,这也就是为什么REST的全名是Representational State Transfer的原因。资源标识符就是URI(Uniform Resource Identifier),不管是图片,Word还是视频文件,甚至只是一种虚拟的服务,也不管你是xml格式,txt文件格式还是其它文件格式,全部通过 URI对资源进行唯一的标识。

REST是基于Http协议的,任何对资源的操作行为都是通过Http协议来实现。以往的Web开发大多数用的都是Http协议中的GET和POST方 法,对其他方法很少使用,这实际上是因为对Http协议认识片面的理解造成的。Http不仅仅是一个简单的运载数据的协议,而是一个具有丰富内涵的网络软 件的协议。他不仅仅能对互联网资源进行唯一定位,而且还能告诉我们如何对该资源进行操作。Http把对一个资源的操作限制在4个方法以内:GET, POST,PUT和DELETE,这正是对资源CRUD操作的实现。由于资源和URI是一一对应的,执行这些操作的时候URI是没有变化的,这和以往的 Web开发有很大的区别。正由于这一点,极大的简化了Web开发,也使得URI可以被设计成更为直观的反映资源的结构,这种URI的设计被称作 RESTful的URI。这位开发人员引入了一种新的思维方式:通过URL来设计系统结构。当然了,这种设计方式对一些特定情况也是不适用的,也就是说不 是所有的URI都可以RESTful的。

REST 之所以可以提高系统的可伸缩性,就是因为它要求所有的操作都是无状态的。由于没有了上下文(Context)的约束,做分布式和集群的时候就更为简单,也 可以让系统更为有效的利用缓冲池(Pool)。并且由于服务器端不需要记录客户端的一系列访问,也减少了服务器端的性能。

使用REST架构

对于开发人员来 说,关心的是如何使用REST架构,这里我们来简单谈谈这个问题。REST不仅仅是一种崭新的架构,它带来的更是一种全新的Web开发过程中的思维方式: 通过URL来设计系统结构。在REST中,所有的URL都对应着资源,只要URL的设计是良好的,那么其呈现的系统结构也就是良好的。这点和TDD (Test Driven Development)很相似,他是通过测试用例来设计系统的接口,每一个测试用例都表示一系列用户的需求。开发人员不需要一开始就编写功能,而只需要 把需要实现的功能通过测试用例的形式表现出来即可。这个和REST中通过URL设计系统结构的方式类似,我们只需要根据需求设计出合理地URL,这些 URL不一定非要链接到指定的页面或者完成一些行为,只要它们能够直观的表现出系统的用户接口。根据这些URL,我们就可以方便的设计系统结构。从 REST架构的概念上来看,所有能够被抽象成资源的东西都可以被指定为一个URL,而开发人员所需要做的工作就是如何能把用户需求抽象为资源,以及如何抽 象的精确。因为对资源抽象的越为精确,对REST的应用来说就越好。这个和传统MVC开发模式中基于Action的思想差别就非常大。设计良好的URL, 不但对于开发人员来说可以更明确的认识系统结构,对使用者来说也方便记忆和识别资源,因为URL足够简单和有意义。按照以往的设计模式,很多URL后面都 是一堆参数,对于使用者来说也是很不方便的。

既然REST这 么好用,那么是不是所有的Web应用都能采取此种架构呢?答案是否定的。我们知道,直到现在为止,MVC(Model-View-Controller) 模式依然是Web开发最普遍的模式,绝大多数的公司和开发人员都采取此种架构来开发Web应用,并且其思维方式也停留于此。MVC模式由数据,视图和控制 器构成,通过事件(Event)触发Controller来改变Model和View。加上Webwork,Struts等开源框架的加入,MVC开发模 式已经相当成熟,其思想根本就是基于Action来驱动。从开发人员角度上来说,贸然接受一个新的架构会带来风险,其中的不确定因素太多。并且REST新 的思维方式是把所有用户需求抽象为资源,这在实际开发中是比较难做到的,因为并不是所有的用户需求都能被抽象为资源,这样也就是说不是整个系统的结构都能 通过REST的来表现。所以在开发中,我们需要根据以上2点来在REST和MVC中做出选择。我们认为比较好的办法是混用REST和MVC,因为这适合绝 大多数的Web应用开发,开发人员只需要对比较容易能够抽象为资源的用户需求采取REST的开发模式,而对其它需求采取MVC开发即可。这里需要提到的就 是ROR(Ruby on Rails)框架,这是一个基于Ruby语言的越来越流行的Web开发框架,它极大的提高了Web开发的速度。更为重要的是,ROR(从1.2版本起)框 架是第一个引入REST做为核心思想的Web开发框架,它提供了对REST最好的支持,也是当今最成功的应用REST的Web开发框架。实际上,ROR的 REST实现就是REST和MVC混用,开发人员采用ROR框架,可以更快更好的构建Web应用。

对开发人员来说,REST不仅仅在Web开发上贡献了自己的力量,同时也让我们学到了如何把软件工程原则系统地应用于对一个真实软件的设计和评估上。

时间: 2024-09-30 11:30:33

什么是REST架构 - z的相关文章

[z]计算机架构中Cache的原理、设计及实现

前言 虽然CPU主频的提升会带动系统性能的改善,但系统性能的提高不仅仅取决于CPU,还与系统架构.指令结构.信息在各个部件之间的传送速度及存储部件的存取速度等因素有关,特别是与CPU/内存之间的存取速度有关. 若CPU工作速度较高,但内存存取速度相对较低,则造成CPU等待,降低处理速度,浪费CPU的能力. 如500MHz的PⅢ,一次指令执行时间为2ns,与其相配的内存(SDRAM)存取时间为10ns,比前者慢5倍,CPU和PC的性能怎么发挥出来? 如何减少CPU与内存之间的速度差异?有4种办法:

我是如何对网站CSS进行架构的

一.写在前面的 都是自己积累形成的一些东西,可能带有明显的个人印记.不是专业内容,不是权威指南,只是展示一点自己的观点,借此希望能与各位优秀的同行交流看法,见解.以得到进步与提高. 二.我所知的一些过往的做法 关于如何处理网站的CSS,各个网站做法都不一样,这随着网站的性质及大小不同,公司前人留下的规范不同,以及CSS工程师的眼界不同而有所不同.由于我从业经历有限,所知甚浅,只能说些肤浅业余的内容,不准确之处欢迎指出. 就CSS文件而言,有的网站分为header.css, body.css, f

【转】微信、陌陌 架构方案分析

来源:http://www.wubiao.info/401 作者:wubiao 微信.陌陌 架构方案分析 近两年.手机应用.莫过于微信.陌陌之类最受欢迎.但实现原理,分享文章甚少. 故,提出两种方案,供分享:不正确之处.敬请留言学习. 目标 解决大型应用(微信.陌陌级别)中.用户经纬度在不断更新.用户查找频繁的问题. (每分钟1000W级) ==============================================================================

微服务架构(Microservice Architecture)

之前一段时间,有听部门架构说起接下来公司要使用微服务架构来研发系统,当时没怎么在意,因为是第一次听说微服务这个名词(果然无知者无畏啊):正好赶上五一假, 我自告奋勇的,接了编写微服务架构培训文档这个任务(也许因为我是文科生,文笔稍微好点).五一假期三天,基本都是在看资料,梳理思路以及编写接下来的培训文档中度过. 下面,就说说我这几天的一些收获吧:先说说资料来源吧:有架构给我的一些资料,以及自己百度和论坛.社区找来的一些资料,权当做一个总结式的简介... 目录如下: 一.微服务架构介绍 二.出现和

排球计分(三层架构)

排球比赛计分,现场工作人员 1.  估计时间:一周左右. 2.  开发 需求分析: 作为一个排球比赛的现场工作人员,我需要统计每一名 队员的得分及技术统计,以便颁发每场比赛的最有价值球员奖, 以及确定赛会的最佳阵容. 设计文档: 在界面通过队球员信息进行操作,可以同步到数据库中.查询分数和统计.从数据库中获取运动员分数 设计复审: 自己. 代码规范: c#对设计进行具体操作: 具体设计: Dal层 public int regist(TeamInfo team) { string strcom

架构师米洛:不懂技术的人不要对懂技术的人说这很容易实现

这是一篇很好的文章.在IT滚了好多年的我,面对非技术人员的催问,这东西做起来难不难的时候,如果我做过我会告诉这东西不难.如果我没做过,我不会说什么,可是这根本满足不了非技术人的好奇心. "这个网站相当简单,所有你需要做的就是完成X,Y,Z.你看起来应该是技术很好,所以,我相信,你不需要花费太多时间就能把它搭建起来." 我时不时的就会收到这样的Email.写这些邮件的人几乎都是跟软件开发技术不沾边的人,或正在研究他们的第一个产品. 起初,当听到人们这样的话,我总是十分的恼怒.他们在跟谁辩

【转载】15年编程生涯,资深架构师总结的7条经验

原文:15年编程生涯,资深架构师总结的7条经验 前言: 这是一篇应InfoQ之邀写的文章, 首发在InfoQ微信公共号上. 大家有空可以多看看InfoQ 网站和公共号 , 是个很有深度的优秀社区. 我和很多人交流过一个有趣的现象,那就是刚毕业到30岁这段时间,会觉得时间过得很慢,总觉得自己还很年轻,但是一旦过了30岁,时间就如白驹过隙,一年又一年飞逝而过. 我自己也是,眼瞅着毕业快15年了,15年间从一个刚毕业的菜鸟,成长为技术骨干,做到架构师的职位,回头看看,当年听取亲戚的一句话,误入计算机行

大数据系统数据采集产品的架构分析

任何完整的大数据平台,一般包括以下的几个过程: 数据采集 数据存储 数据处理 数据展现(可视化,报表和监控) 其中,数据采集是所有数据系统必不可少的,随着大数据越来越被重视,数据采集的挑战也变的尤为突出.这其中包括: 数据源多种多样 数据量大,变化快 如何保证数据采集的可靠性的性能 如何避免重复数据 如何保证数据的质量 我们今天就来看看当前可用的一些数据采集的产品,重点关注一些它们是如何做到高可靠,高性能和高扩展. Apache Flume Flume 是Apache旗下,开源,高可靠,高扩展,

Nova分析(1)——整体架构

Conceptual Diagram Logical diagram Nova is the most complicated and distributed component of OpenStack. A large number of processes cooperate to turn end user API requests into running virtual machines. Below is a list of these processes and their fu