- 浏览: 154140 次
- 性别:
- 来自: northeast
文章分类
最新评论
-
lightgjc1:
好,支持,赞一下
复制表结构的通用存储过程 -
star022:
很有个性~~
tomcat 异常 Exception loading sessions from persistent storag -
我奋斗:
我也觉得,混江湖的吧。
tomcat 异常 Exception loading sessions from persistent storag -
wenjinglian:
你的图片真的 ;豪放。。。
tomcat 异常 Exception loading sessions from persistent storag -
helenxiao520:
[/b][b][b][/b]
什么是集群?
REST 是由 Roy Fielding 在他的论文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。
REST 是英文 Representational State Transfer 的缩写,有中文翻译为“具象状态传输”(参考:《SIP/IMS网络中的Representational State Transfer (REST)和数据分布》)。
—————————————
前面的内容比较枯燥,我说说我自己的理解。
但是 REST 到底是什么呢?论文我看不懂,不过找到一篇更简单易懂的东西:《Building Web Services the REST Way》。
根据这篇文章,我整理了一下我自己对 REST 的理解:
REST 首先只是一种架构样式,不是一种标准。这点和 Ajax 类似,两者都是利用现有的成熟技术。
在 REST 的定义中,一个 Web 应用总是使用固定的 URI 向外部世界呈现(或者说暴露)一个资源。
URI 是英文 Uniform Resource Identifier 的缩写,中文翻译“通用资源标志符”。
“通用资源标志符”是指唯一标识一个资源(xhtml 文件、图片、css 样式表)的字符串。当然了,RFC 中定义的 URI 复杂得多,不过我们此处将 URI 想象成一个人的身份证号码就行了(你不能有两个同时有效的身份证号码,一个号码也不可能同时对应两个人)。而我们天天挂在嘴边的 URL 地址就是 URI 的一种表现形式(个人理解,有错请纠正)。
知道什么是 URI 后,我们来看一个实际例子:
http://www.example.com/photo/logo 指向 example.com 网站(可以视为一个 Web 应用)中类型为 photo,名字为 logo 的资源。我们用浏览器访问这个 URI,看到的将可能是一个 xhtml 文档,其中用 来显示实际的照片。
http://www.example.com/photo/logo 很容易让你想到 URL 重写。事实上,这个地址很可能会在服务器内部处理为 http://www.example.com/photo.php?name=logo 这样的地址。photo.php 是服务器端的一个动态脚本文件,根据 name 参数生成 xhtml 文档返回给浏览器。
现在假设我们要获取这张照片的 XML 文档。XML 文档中包含照片的文件名、文件大小、拍摄日期等等信息。也就是说我们要获取“同一个资源的不同表现形式的数据”。对于这个要求,我们可以很容易的用另一个 URL 地址达到:http://www.example.com/xml/logo。
但是,这就违背了“URI 唯一标识一个资源”的定义。如果我们要获取同一个资源的多种表现形式,那么就要使用更多的 URL,从而给一个资源指定了多个不同的 URI。
而在 REST 中,不管是获取照片的 xhtml 文档还是 XML 文档,或者照片文件本身,都是用同一个 URI,就是 http://www.example.com/photo/logo。
那这是怎么办到的呢?Ruby On Rails 中是通过分辨 HTTP Request Header 信息来分辨客户端是想要取得资源的哪一种表现形式的数据。
当我们用浏览器访问一个网址时,浏览器会构造一个 HTTP 请求。这个请求有一个头信息,其中包括了本次请求接受何种类型的数据。通常浏览器发送的 HTTP 请求头中,Accept 的值都是 */*,也就说接受服务器返回的任何类型的数据。
看到这里,聪明的家伙应该知道了。只要我们指定一个特定的 Accept 参数,那么服务器就可以通过判断该参数来决定返回什么类型的数据。所以在一个采用 REST 架构的应用中,要获取同一个资源的不同表现形式的数据,只需要使用不同的 HTTP 请求头信息就行了。
如果考虑为 Web 应用增加 Web Services,这种技术的价值就体现出来了。比如我写了一个 Delphi 程序,现在只需要构造一个包含 Accept: text/xml 的 HTTP 请求头,然后将请求发送到 http://www.example.com/photo/logo 就可以了。返回的结果就是一个 XML 文档,而不是 xhtml 文档。
因为我们的 HTTP 请求头信息有不同的状态,从而可以获得不同的数据,所以叫做“具象状态传输”
—————————————
除了上面的用法,REST 还有进一步的扩展。
我们在 Web 应用中处理来自客户端的请求时,通常只考虑 GET 和 POST 这两种 HTTP 请求方法。实际上,HTTP 还有 HEAD、PUT、DELETE 等请求方法。而在 REST 架构中,用不同的 HTTP 请求方法来处理对资源的 CRUD(创建、读取、更新和删除)操作:
- POST: 创建
- GET: 读取
- PUT: 更新
- DELETE: 删除
经过这样的一番扩展,我们对一个资源的 CRUD 操作就可以通过同一个 URI 完成了:
http://www.example.com/photo/logo(读取)
仍然保持为 [GET] http://www.example.com/photo/logo
http://www.example.com/photo/logo/create(创建)
改为 [POST] http://www.example.com/photo/logo
http://www.example.com/photo/logo/update(更新)
改为 [PUT] http://www.example.com/photo/logo
http://www.example.com/photo/logo/delete(删除)
改为 [DELETE] http://www.example.com/photo/logo
从而进一步规范了资源标识的使用。
通过 REST 架构,Web 应用程序可以用一致的接口(URI)暴露资源给外部世界,并提供对资源的操作服务。这对于以资源为中心的 Web 应用来说非常重要。例如照片共享网站、用户社区等。
—————————————
Ruby On Rails 1.2 版对 REST 有很好的支持,但要在 PHP 中应用 REST 还需要解决不少问题:
- 如何在服务端判断 PUT、DELETE 请求方法;
- 如何获取用 PUT、DELETE 请求方法中传递的数据;
- 如何获取 HTTP 请求头信息中的 Accept 参数值;
- 如何在浏览器端发起 PUT 和 DELETE 请求。
不过我仔细看了 PHP 文档,我觉得上面几个问题都是可以解决的。
服务端综合使用 $_SERVER[’HTTP_ACCEPT’]、$_SERVER[’REQUEST_URI’]、$_SERVER[’REQUEST_METHOD’]、$_SERVER[’QUERY_STRING’] 这些变量应该可以搞定前面三个问题。而第四个问题则可以用 JavaScript 的 XMLHttpRequest 对象来实现。
不过我想 REST 的真正价值在于 Web Services,而不是通过浏览器操作的应用程序。
这阵子正打算用Rails做个东东,所以开始系统地学习起了Rails。巧合的是,大概两周前,dlee邀请我加入Fielding博士关于REST的那篇论文的翻译团队。可以说Rails和REST这两个最热门的词汇几乎同时挤入了我的生活。随着我对Rails的学习和对[Fielding]的翻译,我也开始对REST产生了一些不太成熟的想法,写在这里与大家分享,同时也起到抛砖引玉的作用,欢迎大家讨论。
先复习一下REST的基本思想。[Fielding]把REST形式化地定义为一种架构风格(architecture style),它有架构元素(element)和架构约束(constraint)组成。这些概念比较晦涩难懂,而且我们做工程的往往并不需要形而上的理解。我们只知道,REST是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。REST提出了一些设计概念和准则:
- 网络上的所有事物都被抽象为资源(resource);
- 每个资源对应一个唯一的资源标识(resource identifier);
- 通过通用的连接器接口(generic connector interface)对资源进行操作;
- 对资源的各种操作不会改变资源标识;
- 所有的操作都是无状态的(stateless)。
对于当今最常见的网络应用来说,resource identifier是url,generic connector interface是HTTP,第4条准则就是我们常说的url不变性。这些概念中的resouce最容易使人产生误解。resouce所指的并不是数据,而是数据+特定的表现形式(representation),这也是为什么REST的全名是Representational State Transfer的原因。举个例子来说,“本月卖得最好的10本书”和“你最喜欢的10本书”在数据上可能有重叠(有一本书即卖得好,你又喜欢),甚至完全相同。但是它们的representation不同,因此是不同的resource。
REST之所以能够简化开发,是因为其引入的架构约束,比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个:index、show、new、edit、create、update和destory,这实际上就是对CURD的实现。更进一步讲,Rails(也是当今大部分网络应用)使用HTTP作为generic connector interface,HTTP则把对一个url的操作限制在了4个之内:GET、POST、PUT和DELETE。
REST之所以能够提高系统的可伸缩性,是因为它强制所有操作都是stateless的,这样就没有context的约束,如果要做分布式、做集群,就不需要考虑context的问题了。同时,它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配:server只负责提供resource以及操作resource的服务,而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。
既然REST有这样的好处,那我们应该义无反顾地拥抱它啊!目前一些大牛(像DHH)都已经开始投入到了REST的世界,那我们这些人应该做什么或者说思考写什么你呢?我觉得我们应该思考两个问题:
- 如何使用REST;
- REST和MVC的关系。
第一个问题假设REST是我们应该采用的架构,然后讨论如何使用;第二个问题则要说明REST和当前最普遍应用的MVC是什么关系,互补还是取代?
我们先来谈谈第一个问题,如何使用REST。我感觉,REST除了给我们带来了一个崭新的架构以外,还有一个重要的贡献是在开发系统过程中的一种新的思维方式:通过url来设计系统的结构。根据REST,每个url都代表一个resource,而整个系统就是由这些resource组成的。因此,如果url是设计良好的,那么系统的结构就也应该是设计良好的。对于非高手级的开发人员来说,考虑一个系统如何架构总是一个很抽象的问题。敏捷开发所提倡的Test Driven Development,其好处之一(我觉得是最大的好处)就是可以通过testcase直观地设计系统的接口。比如在还没有创建一个class的时候就编写一个testcase,虽然设置不能通过编译,但是testcase中的方法调用可以很好地从class使用者的角度反映出需要的接口,从而为class的设计提供了直观的表现。这与在REST架构中通过url设计系统结构非常类似。虽然我们连一个功能都没有实现,但是我们可以先设计出我们认为合理的url,这些url甚至不能连接到任何page或action,但是它们直观地告诉我们:系统对用户的访问接口就应该是这样。根据这些url,我们可以很方便地设计系统的结构。
让我在这里重申一遍:REST允许我们通过url设计系统,就像Test Driven Development允许我们使用testcase设计class接口一样。
OK,既然url有这样的好处,那我们就着重讨论一下如何设计url。网络应用通常都是有hierarchy的,像棵大树。我们通常希望url也能反映出资源的层次性。比如对于一个blog应用:/articles表示所有的文章,/articles/1表示id为1的文章,这都比较直观。遗憾的是,网络应用的资源结构永远不会如此简单。因此人们常常会问这样一个问题:RESTful的url能覆盖所有的用户请求吗?比如,login如何RESTful?search如何RESTful?
从REST的概念上来看,所有可以被抽象为资源的东东都可以使用RESTful的url。因此对于上面的两个问题,如果login和search可以被抽象为资源,那么就可以使用RESTful的url。search比较简单,因为它会返回搜索结果,因此可以被抽象为资源,并且只实现index方法就可以了(只需要显示搜索结果,没有create、destory之类的东西)。然而这里面也有一个问题:search的关键字如何传给server?index方法显然应该使用HTTP GET,这会把关键字加到url后面,当然不符合REST的风格。要解决这个问题,可以把每次search看作一个资源,因此要创建create和index方法,create用来在用户点击“搜索”按钮是通过HTTP POST把关键字传给server,然后index则用来显示搜索结果。这样一来,我们还可以记录用户的搜索历史。使用同样的方法,我们也可以对login应用REST,即每次login动作是一个资源。
现在,我们来复杂一些的东东。如何用url表达“category为ruby的article”?一开始可能想到的是/category/ruby/articles,这种想法很直观。但是我觉得里面的category是不需要的,我们可以直接把“/ruby”理解为“category是ruby”,也就是说“ruby”出现的位置说明了它指的就是category。OK,/ruby/articles,单单从这个url上看,我们能获得多少关于category的信息呢?显然category隐藏在了url后面,这样做到底好不好,应该是仁者见仁,智者见智了。对于如何表达category这样的东西,我还没想出很好的方式,大家有什么好idea,可以一起讨论。
另外还有一种url形式,它对应到程序中的继承关系。比如product是一个父类,book和computer是其子类。那么所有产品的url应该是/products,所有书籍的url应该是/books,所有电脑的url应该是/computers。这一想法就比较直观了,而且再次验证了url可以帮助我们进行设计的论点。
让我再说明一下我的想法:如果每个用户需求都可以抽象为资源,那么就可以完全使用REST。
由此看来,使用REST的关键是如何抽象资源,抽象得越精确,对REST的应用就越好。因此,如何改变我们目前根深蒂固的基于action的思想是最重要的。
有了对第一个问题的讨论,第二个问题就容易讨论多了。REST会取代MVC吗?还是彼此是互补关系(就像AOP对于OOP)?答案是It depends!如果我们可以把所有的用户需求都可以抽象为资源,那么MVC就可以推出历史的舞台了。如果情况相反,那么我们就需要混合使用REST和MVC。
当然,这是非常理想的论断。可能我们无法找到一种方法可以把所有的用户需求都抽象为资源,因为保证这种抽象的完整性(即真的是所有需求都可以)需要形式化的证明。而且即使被证明出来了,由于开发人员的能力和喜好不同,MVC肯定也会成为不少人的首选。但是对于希望拥抱REST的人来说,这些都没有关系。只要你开发的系统所设计的问题域可以被合理地抽象为资源,那么REST就会成为你的开发利器。
所以,所有希望拥抱REST的朋友们,赶快训练自己如何带上资源的眼镜看世界吧,这才是REST的核心所在
发表评论
-
优雅降级/过载保护
2012-06-28 10:51 0何谓降级,如何降级 系统通常提供了多种功能,这些功能会有重要 ... -
Copy-on-write, 写时复制
2012-04-13 17:24 0Oracle.JRockit.The.Definitive.G ... -
思路,临时想法
2012-02-02 16:53 0提高IO效率,均衡、分治,顺序,减少次数 1. 随机IO变顺 ... -
Problem with WebappClassLoader in background thread
2011-09-22 15:24 0Web应用中线程问题(Problem with WebappC ... -
SimpleDateFormat格式化时间与Locale的关系
2011-07-04 17:50 2649遇到格式化时间问题,在英文操作系统环境中,如下 import ... -
缓存文件描述符
2011-06-10 12:46 0文件描述符是一个简单的整数,用以标明每一个被进程所打开的文件和 ... -
IE缓存机制
2011-06-10 12:20 2439一、IE缓存机制 IE的缓存是以URL为标识的文件形式存储。 ... -
Observer, events
2011-06-08 22:32 2扩展性架构&设计 观 ... -
非一致性,放弃分布式事务,舍弃一致性,异步去重,异步设计等
2010-01-27 19:32 0替代分布式事务的解 ... -
HTTP持久连接
2010-01-12 18:14 2985Persistent Connections What ... -
计算字符串中字节长度
2009-02-11 13:14 1173/* * * 计算字符串的字节长度(字母数字计1,汉字及标 ... -
oracle中判断记录是否存在
2009-02-11 12:42 1430避免全表扫描 使用select cal_id from CMS ... -
javascript
2008-07-30 21:24 950JavaScript中包含的几个预定义函数详解 ... -
【转】通过DatabaseLink连接远程Oracle数据表的错误,及其变通方法
2007-09-05 20:36 2507通过DatabaseLink连接远程O ... -
数据仓库与olap基础
2007-05-21 10:34 2802多维数据模型与OLAP实现 2007-05-18 13:41 ... -
复制表结构的通用存储过程
2007-04-19 11:24 1415复制表结构的通用存储过程 <o:p> ... -
【转】数据库设计 术语
2007-04-02 10:30 1169... -
【转】动静态语言的语义思考
2007-03-14 17:12 1764动静态语言的语义思考 ... -
【转载】java操作Excel、PDF文件
2007-03-11 16:37 2013java操作Excel、PDF文件 ... -
【转载】spring 生成Excel和PDF文件
2007-03-11 16:15 4614spring 生成Excel和PDF文件 HTML页面并不 ...
相关推荐
基础传统神经网络算法大杂烩基础传统神经网络算法大杂烩 基础传统神经网络算法大杂烩基础传统神经网络算法大杂烩 基础传统神经网络算法大杂烩基础传统神经网络算法大杂烩 基础传统神经网络算法大杂烩基础传统神经...
它提供了一次学习和探索不同界面设计实践的机会,有助于提升开发者的编程技巧和设计感,同时也为商业项目提供了可以直接借鉴或修改的代码基础。在实际应用中,这些源码可以被用来快速构建具有吸引力的商业应用界面,...
8. **例程和模板**:“labview论坛-labview串口大杂烩”可能包含了各种串口通信的示例程序和用户自定义函数(UDF),这些可以作为学习和快速开发的基础。 9. **同步与异步通信**:了解同步和异步通信的概念,根据...
组织活动小游戏大全_-_[大杂烩].doc
总的来说,“人脸识别大杂烩”涵盖的内容广泛且深入,从基础理论到前沿技术,从算法实现到实际应用,无不体现了这一领域的发展活力和广阔前景。通过不断的研究和创新,人脸识别技术将持续推动社会智能化的步伐。
在IT行业中,"工具大杂烩"通常指的是包含多种不同类型工具的集合,这些工具可能涵盖了开发、测试、运维、数据分析等多个领域。在这个压缩包文件"聚宝盆"中,我们可以推测它可能包含了丰富的IT资源,旨在帮助用户一站...
本压缩包文件“Eclipse技术大杂烩 - 技术贴.chm”显然是一个关于Eclipse使用技巧和技术的集合,其中可能包含了各种实用的教程、常见问题解答和高级功能的深入解析。 在Eclipse的使用中,有几个关键的知识点对于...
在这个“测试大杂烩”中,我们将会探讨软件测试的基础概念、测试用例设计、自动化测试的原理以及在实际项目中如何有效地运用这些知识。 首先,我们要理解什么是软件测试。它是一种系统性的过程,用于评估软件产品...
微信小程序计算器集合,各种小程序计算大杂烩weapp-calculator-master.zip
在这个“labview论坛-labview串口大杂烩源码.zip”压缩包中,我们可以期待找到一系列与LabVIEW串口通信相关的源代码示例。串口通信是LabVIEW中常用的功能之一,它允许设备如传感器、控制器或嵌入式系统通过串行接口...
pot最新资源,包含港澳台和其它,直接放入到pot播放器就可以播放
(大杂烩)proteus仿真MCS51一百例.rar(大杂烩)proteus仿真MCS51一百例.rar(大杂烩)proteus仿真MCS51一百例.rar(大杂烩)proteus仿真MCS51一百例.rar(大杂烩)proteus仿真MCS51一百例.rar(大杂烩)proteus仿真MCS51一百例...
这个"labview论坛-labview串口大杂烩,labview串口通信,LabView源码.zip"压缩包很可能包含了一系列关于LabVIEW串口通信的实例、代码和讨论,旨在帮助用户理解和掌握如何在LabVIEW中实现串口通信。 串口通信基础知识...
罗列了一些网络安全方面的知识,简单介绍了安全测试的知识。
在视频编码领域,H.264(也称为AVC,Advanced Video Coding)和H.262(也称为MPEG-2 Part 2)是两种广泛应用的编码标准。这两种编码技术都旨在提高视频压缩效率,减少存储空间和传输带宽的需求。...
在传统的基础上,随着生活水平的提升,这道菜的配料变得更加丰富多样,包括海鲜和野味,使得烧杂烩杂而有序,味道层次丰富,营养均衡,既满足了人们的口感需求,也符合现代健康饮食的理念。 关于烧杂烩的起源,民间...