Tapestry for Nonbelievers
I. Drobiazko和R. Zubairov合作撰写了一篇文章，详细介绍Apache Tapestry 版本5——一个面向组件web框架。文章向读者展示了创建组件方法，并谈到了Tapestry中的IoC以及Ajax的相关特性。
新闻
文章：深入浅出REST
作者 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的关键原则，使得对这个充满争议的架构的学习变得简单了许多：
- 为所有“事物”定义ID
- 将所有事物链接在一起
- 使用标准方法
- 资源多重表述
- 无状态通信
这些关键原则带来的一些好处列举如下：
对事物使用一致的命名规则（naming scheme），这样你就不需要提出自己的规则——依靠某个已被定义，在全球范围中几乎完美运行，并且能被绝大多数人所理解的规则。
还有：
统一接口使得所有理解HTTP应用协议的组件能与你的应用交互。通用客户程序（generic client）就是从中受益的组件的例子，例如curl、wget、代理、缓存、HTTP服务器、网关还有Google、Yahoo!、MSN等等。
对于那些对REST背后理论感兴趣的人，Tilkov还给出了基本情况介绍，以及这个领域权威内容的链接。
阅读全文：深入浅出REST
不错!支持!
发表人
kudo shinichi
发表于
2007年12月26日 上午7时48分
Re: 不错!支持!
发表人
Richard zhou
发表于
2008年1月4日 上午12时27分
翻译的真好
发表人
dennis zane
发表于
2007年12月26日 下午7时14分
Re: 翻译的真好
发表人
Shayne Yuan
发表于
2007年12月26日 下午8时38分
真的很好
发表人
benjamin tan
发表于
2007年12月27日 下午8时34分
Re: 真的很好
发表人
shi wang
发表于
2008年1月3日 上午6时57分
还是有疑问，请帮助解答。谢谢
发表人
CAO YF
发表于
2007年12月28日 上午3时56分
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
CAO YF
发表于
2007年12月28日 上午4时1分
Re: 还是有疑问，请帮助解答。谢谢（上一个帖子中有乱码，重新发一下）
发表人
kudo shinichi
发表于
2008年1月2日 上午8时48分
我所不明白的问题
发表人
Alex Xu
发表于
2007年12月29日 上午2时41分
Re: 我所不明白的问题
发表人
shi wang
发表于
2008年1月3日 上午6时56分
翻译的真好，终于让我对REST理解了，原文作者写的真是深入浅出，学习REST入门必读
发表人
shi wang
发表于
2008年1月3日 上午6时48分
请教：关于无状态
发表人
Stone Shi
发表于
2008年1月7日 下午8时59分
Re: 请教：关于无状态
发表人
Allan Slim
发表于
2008年1月9日 上午1时54分
有没有完全否和Rest的应用啊，可以参考一下啊，那样更有说服力啊
发表人
paul xu
发表于
2008年1月10日 上午1时3分
Re: 有没有完全否和Rest的应用啊，可以参考一下啊，那样更有说服力啊
发表人
cnoss cheng
发表于
2008年6月5日 下午10时31分
-
我还以为这篇文章被遗漏了呢，快一个月了吧，终于有人翻译了，质量不错，赞一个!
-
比论文通俗易懂多了
-
谢谢支持 主要还是原文自身比较通俗:)
-
确实比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的无缝集成 * 支持分布式资源对象
16 条回复
回复