Tapestry for Nonbelievers
I. Drobiazko和R. Zubairov合作撰写了一篇文章,详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法,并谈到了Tapestry中的IoC以及Ajax的相关特性。
作者 Udi Dahan译者 苑永凯 发布于 2007年12月25日 下午10时31分
尽管Web无处不在,可许多人还是很难将Web的架构原则应用在自己的系统之中。表述性状态转移(REST),Web背后的架构,正在迅速地成为架构师在开发分布式系统时考虑到的可行方案之一。在这篇发表的InfoQ中文站文章中,Stefan Tilkov深入研究了使用REST设计系统的方法,并考察了传统基于接口(interface-based)的设计方法与其的异同。
不知你是否意识到,围绕着什么才是实现异构的应用到应用通信的“正确”方式,一场争论正进行的如火如荼:虽然当前主流的方式明显的集中在基于SOAP、WSDL和WS-*规范的Web Services领域,但也有少数人用细小而洪亮的声音主张更好的方式是:REST。
Tilkov在一开始就列举了REST的关键原则,使得对这个充满争议的架构的学习变得简单了许多:
这些关键原则带来的一些好处列举如下:
对事物使用一致的命名规则(naming scheme),这样你就不需要提出自己的规则——依靠某个已被定义,在全球范围中几乎完美运行,并且能被绝大多数人所理解的规则。
还有:
统一接口使得所有理解HTTP应用协议的组件能与你的应用交互。通用客户程序(generic client)就是从中受益的组件的例子,例如curl、wget、代理、缓存、HTTP服务器、网关还有Google、Yahoo!、MSN等等。
对于那些对REST背后理论感兴趣的人,Tilkov还给出了基本情况介绍,以及这个领域权威内容的链接。
阅读全文:深入浅出REST
我还以为这篇文章被遗漏了呢,快一个月了吧,终于有人翻译了,质量不错,赞一个!
比论文通俗易懂多了
谢谢支持 主要还是原文自身比较通俗:)
确实比REST论文的确通俗易懂多了,准备再去看一遍论文。
看了此文,虽然较那Fielding的那篇论文通俗易懂,但还是没能解决我长期以来的疑问。 各类关于REST的文章都指出,需要给每个资源指定一个URI,那么,这个URI是指什么呢?我一直将URI与URL等同起来看待,虽然我知道它们之间在定义上是有区别的,但在我们的实际运用中(至少是一般情况下),URI是可与URL赞同的。在网上搜索了一些资料,没有哪篇文章能通俗地讲清楚URI与URL的区别。例如:http://www.***.com/orders.aspx?id=5,这是一个URL,但也可以说是一个URI吧?我用代码依据这个URL初始化一个URI后,得到的“绝对URI”是与这个字符串相同的。 另外,每个资源在系统中本来就应该是有唯一的标识符了吧?系统中的一个图片、一个文本文件、一个处理订单的aspx或jsp页面,这些都应该是“资源”吧?它们的URL就是唯一的呀?还需要为其指定一个唯一标识符吗(指URI)? 另外,概念说了那么多,那么究竟一个REST架构的系统应该怎样设计呢?以一个简单的例子为例: 在我们之前的概念中,如果要对订单进行操作,会有一个Class来处理订单的一些方法,如:GetAll(),GetByID(int ID),Delete(int ID)等等。然后我们会提供一个名为Order.asmx的Web Service来依据参数的不同来调用不同的方法并返回XML格式的结果。 那么,REST又有何不同呢? 请指教。谢谢。
看了此文,虽然较那Fielding的那篇论文通俗易懂,但还是没能解决我长期以来的疑问。 各类关于REST的文章都指出,需要给每个资源指定一个URI,那么,这个URI是指什么呢?我一直将URI与URL等同起来看待,虽然我知道它们之间在定义上是有区别的,但在我们的实际运用中(至少是一般情况下),URI是可与URL赞同的。在网上搜索了一些资料,没有哪篇文章能通俗地讲清楚URI与URL的区别。例如:http://www.***.com/orders.aspx?id=5, 这是一个URL,但也可以说是一个URI吧?我用代码依据这个URL初始化一个URI后,得到的“绝对URI”是与这个字符串相同的。 另外,每个资源在系统中本来就应该是有唯一的标识符了吧?系统中的一个图片、一个文本文件、一个处理订单的aspx或jsp页面,这些都应该是“资源”吧?它们的URL就是唯一的呀?还需要为其指定一个唯一标识符吗(指URI)? 另外,概念说了那么多,那么究竟一个REST架构的系统应该怎样设计呢?以一个简单的例子为例: 在我们之前的概念中,如果要对订单进行操作,会有一个Class来处理订单的一些方法,如:GetAll(),GetByID(int ID),Delete(int ID)等等。然后我们会提供一个名为Order.asmx的Web Service来依据参数的不同来调用不同的方法并返回XML格式的结果。 那么,REST又有何不同呢? 请指教。谢谢。
为什么要把REST跟SOAP对立起来? JSP,ASP,PHP难道不也是对HTTP的“滥用”吗?(按照REST的原则) 电话线原本是给电话用的,但是后来人们用它来发传真,又用调制解调器上网,再后来ADSL,现在ADSL+.在这种途径上人们不断地挖掘潜力.为什么HTTP就不行呢?
我觉得之所以强调URI有别于URL就是为了指明RUI并不指代地址,而强调的是标识符。 另外.../orders.aspx?id=5 这种应该不是REST风格的URI,REST风格应该写成类似.../orders/5的样子。 还有你提到的图片,网页,文本文件等应该是资源的表现形式,跟资源并不完全等同。 至于GetAll(),GetByID(int ID)等方法我认为是符合是REST风格的,因为并没有出现GetAllOrders(),GetOrderByID()等特定的API,只要这些方法是统一接口中规定的操作就可以。如果出现了统一接口之外的方法那就要考虑是不是对资源的抽象有问题。
REST这东西我认为当你真的有需要的时候再来学习比较容易理解,否则强行学习理解,容易越学越糊涂。
WS*这些东西过分强调服务端能力了,而没有挖掘Internet基础设施的能力,这样对伸缩性产生了很大的问题,而且像文中提到的链接能力这些都存在问题。Web之所以这么流行,就源于其链接的能力。 根据我个人的理解,现在很多REST的倡导者在说一些技术对HTTP的“滥用”,其实是一种妥协的说法,他们是怕自己的言行激怒一些读者,其实他们真正想说的就似乎现在很多技术在“误用”HTTP。 其实正像你说的,现在就是在挖掘HTTP的潜力。
同感!
文章不错,最近也一直在了解这方面的东西,感觉SOAP与Restful WebService并不是冲突的,而是不同的实现方式罢了。我觉得在应用中关键是把业务方法和HTTP的方法和URI做很好的映射。
RESTful的无状态要求服务器不保存客户端状态,也就是说放弃原先我们常用的Session,那么在有些应用中,比如说银行客户端,比如说简单的论坛,在验证过用户后才开放资源给用户访问,没有Session,服务器难道每次都要重新验证用户么?是通过cookie么?可是很多用户出于安全考虑是关闭浏览器的cookie功能的。
很简单,Rest并不是万灵药,在面对不同的应用类型上不可能全都适合,个人认为高安全性可靠性的应用目前的Rest框架是很难达到要求的
有没有完全否和Rest的应用啊,可以参考一下啊,那样更有说服力啊
向大家推荐一个REST的Java实现,并附加有例子 http://code.google.com/p/jrest4guice/ 特点: * 基于GUICE,内置带事务的JPA实现 * 零配置式服务声明 * 服务的自动扫描注册 * 非侵入式,用户不需要实现特定的接口来实现Restful服务 * 支持Post. Get. Put. Delete操作 * 灵活的注入(支持上下文环境request/response以及参数的自动注入) * 与JAAS的无缝集成 * 支持分布式资源对象
I. Drobiazko和R. Zubairov合作撰写了一篇文章,详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法,并谈到了Tapestry中的IoC以及Ajax的相关特性。
在本文中,Adrien Louis讨论了两种基于ESB的SOA拓扑方案的优缺点:单个公司级ESB vs. 彼此互联的“部门级”ESB系统。Adrien讨论了每种方案对管理、业务监测、治理、可靠性和编配等问题的影响。
InfoQ中文站有幸与IBM中国开发中心Web 2.0首席架构师毛新生聊了聊Project Zero和软件新发展的相关话题,其中包括Project Zero的组织形式、支持的语言、以及未来发展方向等等。
在某个软件产品设计的初始阶段,Segundo Velasquez曾以客户的身份与一个敏捷团队共同工作;Deborah Hartmann就这段经历对他进行了采访。
本视频从互联网的分类讲起,介绍了开放平台的类型、开放的价值以及开放平台对开发者的机会和挑战。然后以雅虎的NCP开放平台为例,讲解了NCP的特点、基本架构和具体的开发过程。
16 条回复
回复