Ajax 和 REST.docx
- 文档编号:30177946
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:26
- 大小:57.46KB
Ajax 和 REST.docx
《Ajax 和 REST.docx》由会员分享,可在线阅读,更多相关《Ajax 和 REST.docx(26页珍藏版)》请在冰豆网上搜索。
Ajax和REST
Ajax和REST,第1部分
Ajax/REST架构风格对于融入式Web应用程序的优点
2006年11月09日
服务器端Web应用程序因采用富应用程序模型和交付个性化内容而具备了融入式(immersive)的特点,这种特点越突出,应用程序架构对Web架构风格REST(RepresentationalStateTransfer)的违背就越多。
这种违背会降低应用程序的可伸缩性,增加系统复杂性。
通过与REST相互协调,Ajax架构将使融入式Web应用程序消除这些负面影响,尽享REST那些出色的特性。
在短短15年中,WorldWideWeb已经从一项研究实验成长为现代社会的技术支柱。
最初发明Web的目的是使人们可以轻松发布和链接信息,现在它已经发展为软件应用程序的可行平台。
但随着应用程序通过使用富应用程序模型和生成个性化内容而获得了更多的融入性,它们的架构对Web架构风格REST(RepresentationalStateTransfer)的违背也越来越多。
这种违背会降低应用程序的可伸缩性,增加系统复杂性。
新兴的AjaxWeb客户机架构风格让融入式Web应用程序与REST架构风格协调一致。
使它们可以尽享REST那些出色的特性,同时又消除了应用程序违背REST准则时带来的不良特性。
本文将介绍为融入式Web应用程序成功结合Ajax和REST的方法与原因。
请访问Ajax技术资源中心,这是有关Ajax编程模型信息的一站式中心,包括很多文档、教程、论坛、blog、wiki和新闻。
任何新信息都能在这里找到。
REST:
Web架构
尽管WorldWideWeb是在数十年的相关研究基础上建立起来的,但它的有效诞生日期是1990年12月,当时TimBerners-Lee完成了Web主要组件的工作原型:
统一资源标识符(URI)、HTTP、HTML、浏览器和服务器。
Web被迅猛采用,远远超过了先驱者们的预期。
在RoyFielding最出名的系列文章中(请参看参考资料),他描述了自己当时的心情:
“尽管对其成功感到兴奋不已,但是Internet开发者社区逐渐开始担心,Web使用的这种快速增长,以及早期HTTP的一些拙劣的网络特性,会快速压倒Internet基础设施所能承担的容量,从而导致突然的崩塌。
”
“一种架构在设计时就应该考虑到一组特性,让它可以满足甚至超越系统的需求。
忽略这些特性可能会导致后期变更干扰整个架构,就像是使用一扇落地窗去取代承重墙会破坏整个建筑结构的可靠性。
”——RoyFielding
Fielding和其他人对Web架构及其是否能够足以支持各种扩展和用法重新进行了审视。
这种重新审视的有形结果包括更新诸如URI和HTTP之类的一些重要标准。
这种重新审视还获得了一些无形但却非常有意义的结果:
为超级媒体应用程序确定了一种新的架构风格,Fielding将其命名为REST(RepresentationalStateTransfer)。
Fielding断言,使用且符合REST设计约束的Web上部署的组件可以充分利用Web的有用特性。
他还警告说,违背REST准则的Web组件都将无法利用这些优点。
早期时,大部分Web站点和简单的Web应用程序实际上都是遵守REST准则的。
但是随着融入式Web应用程序的日益普及,Web应用程序架构逐渐开始背离REST准则了,此后因果循环,情况日益恶化。
融入式服务器端Web架构的问题很难分析清楚,因为在使用这种架构风格的十年中,已经建立起这样一种信仰:
这些问题都是Web应用程序架构所固有的。
实际上,这并非是Web应用程序架构的问题。
而是由服务器端Web应用程序架构风格所产生的问题。
要打破这种偏见,我们来回顾一下整个架构是如何发展到现在这种状态的,这会很有帮助。
我们将说明为什么在Ajax应用程序创建在商业上可行之后,过去接受的很多假设现在都不再成立了。
回页首
Web应用程序的简史
Berners-Lee创造了Web,最初是将Web作为研究人员远程共享文档和在文档之间创建简单链接以加速知识和思想传播的一种手段。
然而,URI标准的架构特征很快实现了除静态文件之外更多内容的共享。
提供静态文档的Web站点
Web上最早的内容由一些静态HTML文档组成,其中有很多到其他静态文档的链接,如图1所示:
图1.提供静态文档的Web站点
REST使静态文档的检索极其高效、可伸缩,这是因为它们可以根据URI和最后修改日期来轻松缓存。
很快开发人员就超越了静态文档的领域,开始动态文档的提供。
早期的动态Web应用程序
Berners-Lee和其他人设计了URI标准,为资源的统一唯一标识提供支持,同时使其表示(HTML、文本等)根据Web客户机(通常是Web浏览器)和Web服务器之间的协商结果而变化。
由于URI将资源标识和资源的底层存储机制区分开来,因此Web开发人员可以创建一些程序,使之检查URI语法,并动态生成文档,将预先定义的UI元素和动态检索的数据(通常是从关系数据库中)合并在一起,如图2所示。
尽管这些文档是生成的,但是它们的缓存特征与静态文件的完全相同。
图2.以嵌入HTML模板代码形式提供数据库记录的Web站点
此类早期应用程序的一个简单例子是统一目录Web应用程序。
这种应用程序通常以如下方式工作:
用户在Web表单中输入名字(例如,BillHiggins),并单击提交按钮。
表单根据输入的名字创建一个URI,并从服务器上请求这个URI的内容(例如GEThttp:
//psu.edu/Directory/Bill+Higgins)。
服务器检查这个URI,并使用这个学生的电话号码和地址来生成一个Web页面。
服务器将所生成的页面发回到用户的浏览器上。
这种交互的一个重要特性是它是幂等的(idempotent),也就是说除非底层资源发生变化(例如Bill修改了自己的电话号码),否则同一请求的结果总是相同的。
这意味着浏览器或代理服务器都可以在本地对BillHiggins的文档进行缓存,只要底层资源没有发生变化,那就可以从本地缓存中检索资源,而不再需要从远程服务器检索。
这种方法能提高用户感受到的响应性,并增加系统整体效率和可伸缩性。
这些早期的动态Web应用程序可以很好地工作,将大量的信息送至用户指尖。
融入式Web应用程序
下一代Web应用程序的目标就是高度融入,提供个性化的内容和富应用程序模型。
在过去十年中,Web开发人员成功创建了这些融入式应用程序。
一个非常恰当的例子是A电子商务站点。
当用户与AmazonWeb应用程序进行交互时,它会创建复杂的客户页面来推荐有针对性的商品,显示浏览历史记录,并显示用户购物车中商品的价格。
回页首
融入式服务器端应用程序和REST
融入式Web应用程序确实非常有用,但服务器端的融入式Web应用程序风格从根本上来说是不符合REST架构准则的。
具体来说,它违背了一项关键的REST约束,并且没有利用REST最为重要的一些优点,因此又产生了一组新问题。
违背了“无状态服务器”约束
REST的“客户机-无状态-服务器”约束禁止在服务器上保存会话状态。
符合这一约束进行设计可以提高系统的可见性、可靠性和可伸缩性。
但是融入式服务器端Web应用程序希望能够为单个用户提供大量个性化内容,因此必须在两种设计之间作出选择。
第一种设计要在每个客户机请求中都发送大量状态信息,因此每个请求都完整地保留了上下文的内容,服务器是无状态的。
第二种解决方案表面上来看比较简单,应用程序开发人员和中间件供应商都比较倾向于这种方法,它只是简单地发送一个用户标识,并在服务器端为这个标识关联一个“用户会话”(如图3所示)。
第二种设计直接违背了客户机-无状态-服务器约束。
尽管它确实可以实现我们想要的用户功能(具体来说就是指个性化),但却对这个架构进行了极大的改动。
图3.融入式服务器端Web应用程序,其中包含了大量服务器端会话状态
Java™Servlet的HttpSessionAPI正是一个此类变动的例子。
HttpSession让我们可以在状态和特定用户之间建立关联。
这个API看起来对于开发新手非常简单。
实际上,它似乎可以将任何对象保存到HttpSession中,并且不需要自己实现任何特定的查找逻辑就可以将这些对象取出来。
但是当我们开始在HttpSession中放入更多对象时,就会开始注意到我们的应用服务器要占用的内存和处理资源越来越多。
很快我们就确定自己需要将应用程序部署到集群环境中来应对日益增加的资源需求。
然后就会认识到,要让HttpSession在集群环境中工作,每个对象都必须实现Java的Serializable接口,以使会话数据能够在集群环境中的服务器间传递。
然后必须确定应用服务器在关机/重启过程中是否要继续维护会话数据。
很快您就会质疑,违背客户机-无状态-服务器约束是否真的是一个好主意。
(实际上,很多开发人员都不了解这个约束。
)
使分布式缓存变为不可能
融入式服务器端Web应用程序的第二个严重后果在于:
它实际上不能利用REST的第一类支持进行资源缓存。
引用Fielding的话来说,“添加缓存约束的优点是可以部分或完全避免某些交互操作,从而可以通过减少一系列交互的平均延迟来提高效率、可伸缩性以及用户可以感受到的性能。
不过这样做的代价是如果缓存中的陈旧数据与通过将请求直接发送给服务器而获得的数据有很大区别,那么缓存的可靠性就降低了。
”
我们可以将融入式Web应用程序近似地看作一个活动实体,它会根据用户提供的新输入内容、其他人输入的新内容以及新的后台数据而不断发生变化。
由于服务器必须根据多个用户与应用程序的交互来生成每个页面,因此我们实际上无法两次生成相同的文档。
因此,Web浏览器或代理服务器无法缓存服务器资源。
有几种解决方案可以用来处理资源无法缓存的问题。
一种就是创建细粒度的资源在服务器端的缓存,这样服务器就可以通过预先组合好的部分来构建一个粗粒度的页面,而不是通过基本元素(HTML和数据)从头开始一步步地构建这种页面了。
但是问题依然存在:
每个请求都会导致大量的服务器处理,这会损害系统的可伸缩性,还可能会对用户感受到的响应性造成负面影响。
无法提供可缓存资源的另外一个结果是:
动态程度相当高的Web应用程序必须显式地禁止搜索引擎和其他类型的“机器人”作出请求,因为处理这类请求的成本都非常昂贵;而在符合REST准则的应用程序中,只需一次性地将某个资源提供给那一类“机器人”,然后对它们的后续访问发送一条简单的“Not-modified”消息即可。
不使用Ajax的客户端的处理
随着访问Web应用程序的用户越来越多,系统需要的资源也会逐渐增加。
可以让服务器来处理这一切,但将需要容量更大的服务器或集群服务器(服务器端状态在集群环境中并不太适用)。
但如果将处理分布到客户机上,那么每增加一名新用户,您就相当于有了一台支持部分新负载的新电脑。
如果将会话状态分布到客户机上,那么就有了一个无状态的服务器——这是可伸缩Web应用程序中令人满意的一项特性。
这看上去应该是种非常明智的做法,那么为什么不按这种方法设计所有融入式Web应用程序呢?
在Ajax出现之前,答案非常简单:
每次用户访问一个新的Web页面时,应用程序状态时就会被销毁。
每次访问一个Web页面时,都要下载一个或一组包含内容的文件(包含在结构化信息中的数据,例如表和列表),以及影响内容外观的样式(例如,红色文本)。
在Web浏览器中,这些信息都是作为文档对象的抽象集来查看的。
下面的列表为例:
Ford
BMW
Toyota
浏览器会认为这个HTML是一个“无序清单”对象,其中包含了3个列表元素;每个列表元素都包含文本。
整个文档可视为一个复杂的相关对象树。
当我们从一个页面浏览到另外一个页面时,浏览器就会销毁当前页面的对象树,并为下一页创建一个新的对象树。
但是为什么要在一个负载过重的服务器上集中这么多的资源消耗呢?
从理论上来说,我们什么时候可以将处理和内存需求分布到客户机呢?
简单的答案是给定传统Web浏览器约束,这是不可行的(请参看不使用Ajax的客户端处理)。
但是Ajax架构风格使开发人员可以将处理和状态需求分布到客户机。
请继续阅读,学习为什么选择使用Ajax风格的融入式应用程序可以继续遵循REST准则,并充分利用它的优势。
Ajax和REST
正如我们前面看到的一样,传统的服务器端Web应用程序将数据的标识和服务器上的动态数据元素合并在了一起,并将所构成的完整HTML文档返回给浏览器。
Ajax应用程序在其主要UI和浏览器中的主要逻辑方面有所不同;基于浏览器的应用程序代码可以在必要时获取新的服务器数据,并将这些数据织入当前页面(请参看参考资料中JesseJamesGarrett有关Ajax的启蒙文章)。
呈现和数据绑定的位置看起来可能是一个实现细节,但是这种区别会导致完全不同的架构风格。
利用有状态Web客户机的优点
人们通常将Ajax应用程序描述成无需在每次点击时彻底地刷新整页的Web页面。
尽管这个描述非常确切,但是根本的动机在于彻底刷新整页会令用户不耐烦,从而无法获得愉快、融入式的用户体验。
从架构的角度来看,整个页面全部刷新的设计甚至非常危险,这种设计使您无法选择在客户机存储应用程序状态,这可能会导致妨碍应用程序充分利用Web最强大的架构设计点的设计决策。
Ajax让我们不需要进行完全刷新就可以与服务器进行交互,这一事实使有状态客户机再次成为可用选择。
这一点对于动态融入式Web应用程序架构的可能性有深远的影响:
由于应用程序资源和数据资源的绑定转换到了客户端,因此这些应用程序都可以享受这两个世界中最好的东西——融入式Web应用程序中动态、个性化的用户体验,以及遵守REST准则的应用程序中简单、可伸缩的架构。
缓存Ajax引擎
设想一下,将A彻底重新实现为一个Ajax应用程序——一个Web页面可以从服务器上动态获取所有的数据。
(出于商业原因,Amazon可能并不希望这样做,不过那是其他文章讨论的话题了。
)由于现在有很多UI和应用程序逻辑都可以在客户机而不是在服务器上运行,根据Garrett的说法,最初加载页面时需要下载Amazon的Ajax“引擎”。
这个引擎包含大量应用程序逻辑(以JavaScript代码实现),另外还有此后将使用从服务器上异步获取的数据填充的UI框架(见图4):
图4.融入式Ajax应用程序
Ajax引擎一个有趣的特征就是:
尽管它包含了很多应用程序逻辑和表示框架元素,但是如果经过恰当的设计,它可以不包含任何业务数据或个性化内容。
应用程序和表示都冻结在部署时。
在典型的Web环境中,应用程序资源可能6个月才会变更一次。
这意味着负责隔离应用程序资源和数据资源的Ajax引擎是高度可缓存的。
DojoToolkit就是一个很好的例子(请参看参考资料)。
Dojo提供了构建时工具来创建一个包含所有应用程序逻辑、表示和风格的压缩JavaScript文件。
由于它终究只是一个文件,因此Web浏览器可以对其进行缓存,这意味着我们第二次访问启用Dojo的Web应用程序时,很可能就会从浏览器缓存中加载Ajax,而不是从服务器上加载它。
我们可以将这种情况与高度融入化的服务器端Web应用程序进行一下对比,后者每次请求都会导致大量的服务器处理,因为浏览器和网络中介不能对缓存不断变化的资源。
由于Ajax应用程序引擎只是一个文件,因此它也是可以使用代理缓存的。
在大型的企业内部网中,只要有一名员工曾经下载过某个特定版本的应用程序的Ajax引擎,其他任何人都可以从内部网网关上上获取一个缓存过的拷贝。
因此对于应用程序资源来说,经过良好定义的Ajax应用程序引擎符合REST准则,与服务器端Web应用程序相比,它具有显著的可伸缩性优势。
缓存Ajax数据
用户浏览一个AjaxWeb站点,加载Ajax应用程序引擎,最好是从浏览器缓存中加载的,否则就从本地代理服务器加载。
那么对于业务数据来说情况如何呢?
由于应用程序逻辑和状态都在浏览器上驻留并执行,因此应用程序与服务器的交互就与传统Web应用程序的方式有很大的不同。
不需要获取混合的内容页面,只需要获取业务数据即可。
现在回到A的例子上来,假设我们点击了一个链接,要查看有关设计模式的一本书籍。
在A目前的应用程序中,链接点击操作会发送很多标识所请求的资源的信息。
它还会发送很多会话状态信息,这让服务器可以创建一个新页面,其中可以包括之前的状态(例如最近查看的内容)、个性化信息(例如您在1999年购买的书籍)以及实际的业务资源本身。
应用程序是动态且高度个性化的——但是却不能缓存,也无法伸缩(正如Amazon所示范的一样,这些架构问题都可以通过投入大量资金构建基础设施来克服)。
现在我们考虑一下这个操作在(假想的)Ajax版本的应用程序中的情况。
对于“最近查看的内容”并不需要进行处理。
当我们点击某个链接时,这些在页面上已经存在的信息并不会消失。
有两个请求很可能会与设计模式的书籍有关:
/020*******(其中0201633612是设计模式书的ISBN号)
/PurchaseHistory/0201633612/bhiggins@
第一个假定的请求会返回有关书籍的信息(作者、标题、简介等);其中并没有包含特定于用户的数据。
特定于用户的数据意味着当更多用户请求相同的资源时,很可能会从Internet上的中间节点上来检索缓存版本,而不是从原始服务器上检索这些资源。
这种特性会降低服务器和总体网络负载。
另外一方面,第二个请求包含了特定于用户的信息(BillHiggins的购买该书的历史记录)。
由于这些数据包括一些个性化信息,因此只有一名用户需要从这个URI中获取并缓存数据。
尽管这种个性化数据并没有非个性化数据的可伸缩特性,但是重要的问题是这些信息都是直接从URL中获取的,因此都具有这样的正面特征:
它们都不会妨碍其他可缓存的应用程序和数据资源的缓存。
Ajax和健壮性
Ajax架构风格的另外一个优点是它可以轻松处理服务器的故障。
正如我们前面介绍的一样,具有融入式用户体验的服务器端Web应用程序通常会在服务器上保存大量的用户会话状态。
如果服务器发生了故障,会话状态就丢失了,那么用户就会体验到非常奇怪的浏览器行为(“为什么我又回到主页上来了?
我的购物车中的东西都到哪里去了?
”)。
在采用有状态客户机和无状态服务的Ajax应用程序中,服务器崩溃/重新启动对于用户来说都是完全透明的,因为服务器崩溃不会影响会话状态,这些都保存在用户的浏览器中;无状态服务的行为是幂等的,可以由用户请求的内容来单独确定。
回页首
承诺和问题
对于我们称为融入式Web应用程序的那些Web应用程序来说,设计良好的Ajax/REST应用程序在用户体验、响应性和可伸缩性方面都远远超过传统的服务器端Web应用程序。
然而,一种架构风格的运行时特征对于软件项目和Web应用程序来说并非是决定成功的惟一因素。
在创建Ajax/REST应用程序时有一些非常困难的非运行时问题,包括大规模JavaScript开发、文化问题和打包问题。
我们将在另外一篇文章中讨论有关文化的问题,其他内容留待我那些研究Ajax的同僚们去处理。
致谢
非常感谢我的同事ChrisMitchell、JoshStaiger、PatMueller、ScottRich和SimonArcher为本文提供的非常有用的技术反馈。
我还要感谢Redmonk分析公司的JamesGovernor和SteveO'Grady,是他们最初鼓励我考虑REST风格的Web服务。
Ajax和REST,第2部分
应对Ajax软件开发的挑战
2006年12月18日
Ajax的流行程度呈爆炸式增长。
老式的Web框架正在为支持Ajax而自行革新,新的纯Ajax框架正在开发之中,很多组织正在考虑采用Ajax,或者已经开始了构建Ajax应用程序的工作。
但在所有这些悸动之中,只有相当少的组织成功开发了Ajax应用程序。
本文是分为两部分的系列文章的第二部分,本文将帮助您决定是否应在实际IT应用程序中使用Ajax,旨在提高您在Ajax开发中取得成功的机会。
在这个共分两部分的系列文章的第1部分中,我们讨论了对于那些需要动态和个性化的用户界面,同时又要求可伸缩性的Web应用程序来说,Ajax/REST架构风格可能带来的好处。
给定这些需求之后,我解释了为什么相对于传统的服务器端Web应用程序架构风格来说,Ajax/REST极为出色。
但只有在您成功设想、规划、开发、测试和部署了Ajax应用程序之后,用户才能享受这些美好的运行时特性。
本文说明了Ajax/REST应用程序的开发时特性的问题。
其目标是为那些有兴趣在实际应用程序中使用Ajax的读者解答两个重要的问题:
是否应该在自己的IT应用程序中使用Ajax技术吗?
如果答案是肯定的,那么应怎样来提高成功开发和部署Ajax技术的机会?
Ajax/REST架构风格的新兴给使用传统服务器端Web应用程序风格的组织带来了一些挑战。
尽管与传统模型相比,Ajax具有许多引人注目的架构优点,但立即全面转换成纯粹的Ajax/REST架构对于所有组织来说并不现实。
那些缺乏Ajax开发技巧的组织可向现有服务器端Web架构逐渐、增量式地添加Ajax功能,从而开始采用Ajax技术。
随着这些组织在Ajax/REST使用方面的经验逐步增加,他们就可以安心地尝试更有趣、更有野心的项目。
请查看Ajax资源中心,这是您获得Ajax编程模型的一站式场所,其中包含文章和教程、论坛、blog、wiki、事件和新闻。
任何事件都会在这里报导。
您是否应该使用Ajax?
Ajax是一种由一组技术构成的架构风格。
这些技术本身并没有好坏之分;它们都是中立的。
只有在某些组织能够应用某种技术来解决特定的问题或满足特定的需求时,这种技术才会或多或少地有用。
因此要回答“我应该使用Ajax吗?
”这个问题,您必须评估自己的组织正在尝试解决的问题是什么,Ajax可以对您实现目标提供怎样的帮助(还是根本就帮不上忙),以及您的组织是否具有项目成功所需要的恰当人员。
考虑采纳选项的范围
我们可能会纳闷,“采纳Ajax”到底是什么意思。
要利用Ajax,组织并不需要重新编写使用纯Ajax/REST架构的程
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Ajax REST