论坛首页 Java企业应用论坛

Java REST框架一览

浏览 93270 次
该帖已经被评为精华帖
作者 正文
   发表时间:2007-06-02  
目前宣称支持REST的Java框架包括以下这些:
Restlet(http://www.restlet.org/
Cetia4(https://cetia4.dev.java.net/
Apache Axis2(http://http://ws.apache.org/axis2/
sqlREST(http://sqlrest.sourceforge.net/
REST-art(http://rest-art.sourceforge.net/

以下对这些框架进行了较为全面的分析。

Restlet,最新版本1.0.1
特点:完全抛弃了Servlet API,作为替代,自己实现了一套API。能够支持复杂的REST架构设计。
缺点:
1. 虽然也可以运行于Web容器中,但是难以利用Servlet和JSP等资源。因为需要另外学习一套API和概念,学习成本比较高。
2. 完全不支持服务器端的HTTP Session,强制完全基于无状态服务器模型来做开发。对于基于浏览器的应用来说,开发难度较高。
3. 自身没有包括与Spring的集成,可以使用第三方代码与Spring集成,集成难度较大。
4. 文档不是很丰富,大多比较简短,很多时候需要自己去读代码,或者到其wiki上去查找。
5. 没有内建的国际化支持。
优点:
1. 有内建的HTTP认证机制,不需要另外开发安全机制。
2. 灵活性较高,支持更多的REST概念,支持透明的内容协商,适合于开发更加强大的REST组件(不限于服务器端应用)。
3. 零配置文件,全部配置通过代码来完成。

相关资源:
功能列表:http://www.restlet.org/about/features
简介:http://www.restlet.org/about/introduction
教程:http://www.restlet.org/documentation/1.0/tutorial
FAQ:http://www.restlet.org/about/faq

Cetia4,最新版本1.0
特点:基于Servlet API开发,可以运行于所有的Web容器中。
优点:
1. 可以充分利用Servlet API和JSP等资源,需要额外学习的概念较少,学习成本较低。
2. 对于传统的Web应用,可以使用服务器端HTTP Session;对于Web服务类应用,不使用HTTP Session,基于无状态服务器模型做开发。
3. 自身包括了对于Web MVC的支持,熟悉Web MVC框架的开发者很容易理解。还内建了参数映射、参数验证等等传统Web MVC框架所支持的功能。
4. 内建了自己特有的导航对象栈的概念,对于支持传统的Web应用的开发(基于浏览器的导航)非常有帮助。
5. 提供了JSP标签库,对于传统的基于HTML表单的Web开发非常有帮助。
6. 支持与SiteMesh相配合,由SiteMesh来支持页面布局的重用。
7. 内建有与Spring的集成,集成起来非常容易。
8. 配置文件完全基于标准的web.xml,不需要额外的配置文件。大量使用默认配置,一般情况下足以满足常见的需求。
9. 拥有很好的文档。
10. 有内建的国际化支持。
缺点:
1. 没有内建的HTTP认证机制,需要自行开发安全机制。
2. 对于内容协商的支持比较弱,仅支持HTML和XML格式的表现。需要加以扩展才能支持其他格式的表现。

相关资源:
教程:https://cetia4.dev.java.net/files/documents/5545/38989/cetia4_tutorial.pdf

Axis2,最新版本1.2
特点:同时支持SOAP和REST风格的Web Service。
缺点:
1. 仅仅支持GET与POST方法。
2. 仅仅是以REST风格暴露出Web服务,数据格式仍然是包含SOAP封装的XML,不能使用更加有效的格式。
3. 只支持同步的调用方式。
4. 仅仅提供了以SOAP方式暴露Web服务的最小化的支持,不支持全面的REST架构设计。

相关资源:
简介:http://ws.apache.org/axis2/1_2/rest-ws.html

sqlREST,最新版本0.3.1
特点:
1. 为任何可以通过JDBC访问的数据库提供Web服务访问接口,自动将REST风格的HTTP请求转换为相应的数据库SQL语句,并将数据库中的记录编码为XML格式传给客户端。是REST风格的HTTP请求到数据库中的数据的直接映射。
2. 基于Servlet API开发。
缺点:
1. 因为是REST风格的HTTP请求到SQL语句的直接映射,因此强制使用以SQL和关系数据库为中心的数据建模设计方法,不支持面向对象的设计。灵活性很低,难以实现较为复杂的业务逻辑。
2. 因为资源的定义仅限于数据库的表,难以实现更高层次的抽象,必然会导致非常细粒度的API。应用的性能和可伸缩性都难以保证。

相关资源:
教程:http://sqlrest.sourceforge.net/5-minutes-guide.htm

REST-art,最新版本0.2
特点:一个旨在替换复杂的SOAP框架的REST框架,用来作为替代SOAP方便地发布Web服务的工具。不是基于Servlet API开发。
缺点:
1. 目前尚处于刚刚起步的阶段,功能非常少。
2. 不是基于Servlet API,带来了额外的学习成本。

相关资源:
教程:http://sourceforge.net/docman/index.php?group_id=175132
   发表时间:2007-06-02  
Cetia4应该算是目前比较成熟的了,而且也不排斥传统的MVC架构。只是REST框架在java世界里似乎并不是热门。
0 请登录后投票
   发表时间:2007-06-02  
dennis_zane 写道
Cetia4应该算是目前比较成熟的了,而且也不排斥传统的MVC架构。只是REST框架在java世界里似乎并不是热门。

因为Java社群似乎还在迷恋SOAP。
不过即便是EAI,很可能IBM也会舍SOAP而转向REST。
0 请登录后投票
   发表时间:2007-06-04  
gigix 写道
dennis_zane 写道
Cetia4应该算是目前比较成熟的了,而且也不排斥传统的MVC架构。只是REST框架在java世界里似乎并不是热门。

因为Java社群似乎还在迷恋SOAP。
不过即便是EAI,很可能IBM也会舍SOAP而转向REST。


技术是技术,市场是市场。往往最受欢迎的技术不一定是最先进的。SOA经过这些年的宣传和推广,已经为大多数想整合信息的公司所熟悉,SOA的产品自然比较好卖。
不管是SOA还是REST,都只是实现层面上的东西。选择一个,不选择另一个,对于买的人来说只不过换了个忽悠的词汇而已。
0 请登录后投票
   发表时间:2007-06-04  
楼上的跑题了,SOAP!=SOA。
0 请登录后投票
   发表时间:2007-06-05  
SOA和REST不是对立的吧
0 请登录后投票
   发表时间:2007-06-06  
CXF 也提供了对REST的支持
http://cwiki.apache.org/CXF20DOC/restful-services.html

同时 JAX-RS(JSR-311)开始着手定义Rest API的
下面是RI的一些实现
http://developers.sun.com/docs/web/swdp/r1/rest-impl/docs/getting-started.html
0 请登录后投票
   发表时间:2007-06-07  
REST的优势到底是什么?开发效率?文档的管理?url的直观?还是其它的什么优势呢?
0 请登录后投票
   发表时间:2007-06-07  
joyjiang 写道
REST的优势到底是什么?开发效率?文档的管理?url的直观?还是其它的什么优势呢?

REST的主要优势在我看来其实在于它是一种对于服务器的更加有效的抽象方式。

对于基于网络的应用来说,你怎么样看待服务器,就会产生什么样的架构风格,随之产生与该架构风格相关的交互模式。

RPC架构风格将服务器看作是由一些过程组成,客户端调用这些过程来执行特定的任务。SOAP就是RPC风格的一种架构。过程是动词性的(做某件事),因此RPC建模是以动词为中心的。

分布式对象架构风格认为服务器是由一些对象和对象上的方法组成,客户端通过调用这些对象上的方法来执行特定的任务。并且客户端调用这些对象上的方法应该就像是调用本地对象上的方法一样,这样开发就可以完全按照统一的面向对象方法来做。但是很可惜,这样的抽象并不是很有效,因为分布式对象与本地对象存在着巨大的本质差别,想要掩盖这些差别很多时候甚至是有害无益的。

REST架构风格并没有试图掩盖这些差别,而是将服务器抽象为一组离散资源的集合。资源是一个抽象的概念,而不是代表某个具体的东西。注意:要真正理解REST,就一定要增强自己的抽象思维能力,充分理解到资源是抽象的。如果完全不具有抽象思维的能力,一定要将资源与数据库中的一张表或服务器端的一个文件(HTML、Servlet、JSP、etc.)一一挂起钩来,就无法真正理解REST了。资源是名词性的,因此REST建模是以名词为中心的。

上述是目前基于网络的应用的主要的三种抽象方式。这三种不同的抽象方式会严重影响客户端与服务器的交互模式,而不同交互模式的交互效率差别相当大。分布式对象的交互模式很多时候效率很低,因为掩盖了分布式对象与本地对象的差别,很多时候都会导致细粒度的API(需要一再强调才能让一些不明就里的架构初哥按照正确的方式来做设计)。实践已经证明,与RPC和分布式对象相比,REST是一种对于服务器更加有效的抽象方式,将会带来粒度更大和更有效率的交互模式。这样的效果与Fielding设计REST的初衷是吻合的,REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的从来不是性能和可伸缩性,而是互操作性。除非出现奇迹,否则你种什么,就应该长出来什么。你种的是瓜,长出来的就是瓜;你种的是豆,长出来的就是豆。
Fielding 写道
REST提供了一组架构约束,当作为一个整体来应用时,强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减少交互延迟、增强安全性、封装遗留系统的中间组件。


有人认为REST不是面向对象的,其实REST虽然没有分布式对象那么面向对象,在我看来至少比RPC更加面向对象。按照《企业应用架构模式》,以动词为中心建模是什么?是不是就是事务脚本?以名词为中心建模是什么?是不是就是领域模型?这就扯远了,网络通信是否一定需要实现为面向对象的形式,我认为是不需要的。

dlee 写道
REST的主要优势在我看来其实在于它是一种对于服务器的更加有效的抽象方式。

这句话等于是,我先把一个骨架放在这里,还没有用血肉来充实它,也就是还没有举出具体的实例来。具体的实例以后我们还需要来详细讨论。REST是非常简练的,同时又是一种非常强大的抽象方式,在我看来就是从根本上简化Web开发的一味良药。
7 请登录后投票
   发表时间:2007-06-12  
JAVA笨笨 写道
buffalo
buffalo是集成AJAX的,与这个帖讨论的无关吧。。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics