当我第一次听到REST这个概念的时候,我被怔住了,为什么呢?因为我觉得自己太浅薄了,计算机以及计算机网络是一个太过于神奇的东西。

状态表述转移
在REST的世界中,资源即状态,而互联网就是一个巨大的状态机:每个网页是其一个状态;url是状态的表述;REST风格的应用则是从一个状态迁移到下一个状态的状态转移过程。早期互联网只有静态页面的时候,通过超链接在静态网页间浏览跳转的page->link->page->link…模式就是一种典型的状态转移过程。

也就是说早期的互联网就是天然的REST,直接的表明我们现在都偏离了这个概念,偏离了互联网这个REST初态!我们为什么要这么做?我们为什么会在偏离REST之后的这几年开始重新审视这个概念?重视它?

无状态服务器
REST风格应用可以实现交互,但它却天然地具有服务器无状态的特征。在状态迁移的过程中,服务器不需要记录任何Session,所有的状态都通过url的形式记录在了客户端。PS:更准确地说,这里的无状态服务器,是指服务器不保存会话状态(Session);而资源本身则是天然的状态,通常是需要被保存的;本文提到的无状态服务器均指无会话状态服务器。

所有的状态都通过URL的形式记录在客户端?我们的购物车代码可以删除了,完全可以通过URL来表达?原来服务器费尽心思在无状态协议http上做的session都可以废掉了?JdonFrameWork,Seam,EJB中的状态管理组件相对REST是矛盾吗?banq在把jdon框架拓展为真正的RESTful的时候会保留Stateful这个Annotation吗?


[该贴被oojdon于2009-07-14 13:31修改过]

很高兴见到oojdon又发言了。

重新审视Web架构,发掘Web架构背后的故事,就是REST精神。

现在由于互联网已经影响社会,原来封闭的各大网络已经开始融入互联网,比如移动 有限电视等等,这些网络以语义Web加入互联网同时,也在对Web进行冲击。

比如移动和有限电视机顶盒都是在客户端下载专门软件,这个方面代表就是QQ,那么QQ这种C/S代表未来,还是浏览器这种方式代表未来呢?

所以,我们必然要探究,为什么浏览器Web这么简陋,还打败了Java applet,是什么让Web开发和发布运行变得如此普及?这背后就是REST。

有了REST,对于客户端是专用delphi/java/C++软件还是浏览器或新的RIA技术,都无所谓了,因为本质是一致的。

关于oojdon担心的服务器端维护状态一事,是需要移植到客户端来完成,但是无论客户端和服务器端,应该对用户开发来说不构成太大影响,这就是好的ROF应该做到的。


希望banq早日放出RESTful的jdon框架,在国内再开先河,呵呵。
我也很想来完成一部分工作,但我知道到这也只是想想而已,REST太高深了。

最近工作很忙,在努力学习sql,累了就上jdon看一下,看看我那未完成的hibernate版jivejdon有多少人在关注,然后闭上眼思考一下领域驱动设计的路还有多长!
[该贴被oojdon于2009-07-14 15:59修改过]

状态分两种,用户Session相关状态,还有一个是应用级别状态,如状态机,一般是和业务逻辑有关,用户相关的状态保存到客户端,可以用AJAX RIA技术实现,服务器端还是保存状态机,将URI与状态机对应起来。


搞REST状态图就很重要,REST和工作流就有天然联系。以往工作流都是过于依赖数据表,因为要靠数据表保存中间状态,现在有了REST,可以分开保存了,看一个REST和workflow结合的例子:

How to GET a Cup of Coffee:
http://www.infoq.com/articles/webber-rest-workflow
[该贴被banq于2009-07-15 09:21修改过]

REST概念一直很模糊,看了这个帖子,有点概念了.

rest还是比较实用于查询较多,但是更新较少的场合。更加适用于查询系统,我感觉

REST API框架有几个:Jersey, RESTEasy(JBoss的), CXF 和 Restlet, Spring 3.0也支持REST了,还有国人做的一个轻量框架JRest4Guice。

但是这些框架严格来说,不符合Roy博士关于REST API定义,这些人都是有Web服务背景的人,以为REST只是Web服务的一个升级,一种JAX-RS实现,其实完全错误了。

一个REST API如果没有对状态或状态机的良好支持,能叫REST吗?REST名字中就有一个State状态含义啊。

所谓REST框架,不是提供几个CRUD操作,在组件上标记一下/xxxx/{id}就算REST了。

Restlet是唯一一个在JAX-RS之前出现的架构,用Restlet意味着不能使用servlet,所以主流的服务器跑不了,必须结合Mina等自己构建服务器,所以可投入生产性极低。

>主流的服务器跑不了
是REST方向和现在主流服务器方向完全不一样,现在主流服务器是被JavaEE标准引导,其中最大不同就是HttpSession用户状态服务器处理,特别是有态Bean,使用了REST,EJB就成了半个残废。

从这里也可以看出,REST其实是皇帝新装中那个诚实小男孩,他说出了Web本质,而EJB等主流标准技术则是皇帝的新装,误导了整个业界。

曾经有很多JavaEE服务器集群专家建议,不要往HttpSession中放太多数据,如果HttpSession数据太多,Web服务器之间Session数据同步就占据主要工作了。而且在很多领域,比如移动,就无法为某个手机端生成唯一的Session,也就是无法使用Session。

所以,事情本可以这么简单的,用户的状态用户自己来处理,不要搞到服务器端了。这也是RIA技术盛行的一个背后原因。

比较各JAX-RS实现:
http://www.infoq.com/cn/news/2008/10/jaxrs-comparison

[该贴被banq于2009-07-22 10:00修改过]

但是考虑如今政府项目受到政府采购方式的制约,比如你根据需求分析现有的情况下用Rest方式设计最佳,最节省资源,但是回到现实你不可能要求政府采购服务器“必须采购支持JAX_RS规范的服务器”,你也不可能跟信息中心主任说“我们这个采用RestFul架构,不需要使用服务器”,服务器采购原本应该是架构设计者通过系统架构定型之后的决定,但是在中国政府项目里,采购服务器和招开发商是两个独立的过程,脱节的过程,所以一些改进型技术,在这里终究只能是梦想。

所以我们总是无奈于“好的技术思路”和“可工程化,可生产化”之间的巨大差距,有些技术终究只能停留在笔记本里的那些Demo上。

有几个问题,对于用户状态,是不是需要把它的流程打散到不同的服务器当中,因为我觉得用户状态直接通过session分配到不同服务器就可以降低负担。
还有一种状态是全局状态变换,而这种状态变换不依赖具体个体,就是说它不去区分用户状态,任何用户以相同的方式接入一个服务器并取得结果后都应该得到一致的状态。那这样不是只要负载均衡器就够了吗?
具体的说,楼主文中的“想将这三个状态分离分散到多台服务器上,除非重写服务器端代码,否则无能为力”,但是这里的状态并不依赖于某个用户,任何两个用户只要他们的输入相同,就会得到相同的输出。如果输出相同,因为有负载均衡器存在,它下一次的请求自然就会被分配到空闲的服务器上。问题就是是不是有必要把那个接口也打散到多台服务器上,是不是有必要让服务器从事专一作业。

>但是考虑如今政府项目受到政府采购方式的制约,比如你根据需求分析现有的情况下用Rest方式设计最佳,最节省资源,但是回到现实你不可能要求政府采购服务器“必须采购支持JAX_RS规范的服务器”,你也不可能跟信息中心主任说“我们这个采用RestFul架构,不需要使用服务器”,服务器采购原本应该是架构设计者通过系统架构定型之后的决定,但是在中国政府项目里,采购服务器和招开发商是两个独立的过程,脱节的过程,所以一些改进型技术,在这里终究只能是梦想。

不仅仅是Rest,很多其他技术,比如异步web,需要服务器支持ARP,目前Glassfish、Jetty6、tomcat6 comet支持,但是如果政府采购一个weblogic(不知道weblogic是否支持ARP),很可能会让你得意洋洋异步web应用构建计划最终泡汤。

REST不是CRUD 增删改查。
http://www.infoq.com/cn/news/2009/08/CRUDREST

REST架构风格的常见实现是基于HTTP协议及其相应动作(如POST,GET, PUT和DELET)的。而且,这些动作经常会被实现者映射为CRUD术语——Create,Read,Update和Delete。

CRUD不适合于REST的最大原因是架构上的,REST的核心是使用超媒体实现的协议状态机。

CRUD服务是SOA的反模式:
1.限制了服务的整体概念——没有业务逻辑。
2.暴露了内部的数据库结构,或者数据接口,而不是仔细考虑后的接口。
3.鼓励直通服务和数据的做法。
4.建立的是块(Blob)服务(数据源)
5.鼓励细小的多重服务(为块服务定义多重接口),而忽略了分布式计算的若干谬误。
6.仅仅是“批着羊皮”的C-S结构。

仅仅采用诸如HTTP,XML,JASON等标准(尽管他们很有用)还不能构成 REST,而只有采用了REST架构才算真正的REST。

REST和SOA类似,它不是一组标准和流行的API,而是一种架构模型,这才是需要去理解和遵循的。

banq语:赞同,观点和我在本篇阐述思想一致。下一次有机会写一个SOA vs. REST,现在SOA派的人贬低RETS,把REST看成是RPC或CRUD,从而认为REST的C/S是强耦合,和SOA的消息中间松耦合架构不一样,其实这是一种强权畏惧新生事物的变态心理。

1、REST一直强调资源是一种映射,不能绑定到具体的实例。那么http://localhost:8080/book/new可能返回最新的图书信息,这个信息随着时间的变化而变化。但是在没有REST概念的情况下,我们获取最新的图书可能是http://localhost:8080/bookaction?method=new获取,那么也满足“信息随着时间的变化而变化”的资源定义,http://localhost:8080/bookaction?method=new难道就不算“资源是一种映射”么?

2、REST强调“分层”和“统一接口”,这里的统一接口指的是什么,比如一个分布式超媒体系统中,请求先发送到DNS,经过解析发送到Apache Http Server,经过处理发送给Tomcat处理请求,可以把DNS,APACHE和Tomcat看作连接器,其中的统一接口指的是?
(1)普通请求发送给不同DNS的数据格式相同?如果这个层面那不需要REST已经能实现
(2)数据从客户到DNS服务器和从DNS服务器到Apache服务器之间的格式相同,这一点即便加入REST也不可能,因为Apache到tomcat是AJP13协议,怎么可能引入一个架构风格而改变