RESTful架构是否适合“需授权访问的数据库型企业应用”？

RESTful架构是否适合“需授权访问的数据库型企业应用”？

 

首先，定义一下“需授权访问的数据库型企业应用”：其实也就是大多数（绝大多数？）j2ee开发人员要面对的那种应用，数据存储是一堆业务表，表的域比较多，表之间有关系；业务逻辑比较多，一部分是简单的增删改查，一部分是由简单增删改查组合而成的复杂操作，进入系统之前必须登录，只有授权的用户才允许进行业务操作（包括查看）。

 

REST、RESTful的资料看了一些，总感觉RESTful并不适合这类应用,主要依据是：

 

1、这类应用session（及背后的cookies）是必须的，服务器端多少会有一些会话State（比如"用户名"），肯定要违背REST服务器Stateless 原则。

 

2、这类应用任何Proxy Cache(及其他服务器之外的Cache)都是不允许的，因为非授权用户不可访问任何信息，因此无法利用REST强调的Cacheable优势。

 

3、这类应用面对的“数据对象”和REST中的“Resource”应该是不同的，后者偏向于表达那种无结构的对象（比例文档，图片，音视频），对其进行的操作绝大多数时候针对对象整体(既操作本身不关系对象内部的数据构成)，因此可以用POST/GET/PUT/DELETE(CURD)等四个基本动词来表达；而前者大多数情况下，是复杂的、结构化的对象，对他们的操作除了整体操作，还有很多针对其局部的操作（既操作涉及对象的内部结构），四个基本动词远不够用，在不扩充动词的情况下，只能让一个动词表达多个操作，这种设计并不符合REST简单优美的声誉。

 

4、这类应用的“数据对象”之间很多时候是相关的，对某个对象的CURD操作经常同时需要对其他对象的CURD操作，如果把这些相关操作（2个以上）放在一个HTTP请求中完成，则使用四个基本动词来表达是语义不确切的；如果把这些相关操作分成多个HTTP请求，则相关操作的Transaction是无法保证的。

 

上面四点中，1、2对REST的违背是很明显的，3、4也很容易看出来，我的问题是，难道RESTful架构并不适用主流的企业应用（非企业“级”应用:-)），而只适用于像Javaeye这样的向公众提供信息服务的“资源型”网站？

 

另外还有几个主题之外的RESTful疑问，一并请教：
a、现在很多论坛有一个功能：必须回复才能看到主帖，但看到和看不到时的访问URI是相同的，这种设计是否违背REST？
b、基本上论坛帖子都有访问次数统计，其实就是GET操作的时候改变了服务器State，应该也是违背REST吧？
c、只使用POST/GET是否也能实现RESTful？我看Fielding的论文中并没有提到必须使用PUT/DELETE。
d、在《RESTful Web Services》的序言中，作者写道：

 

In that first version of HTTP, cleverly disguised as a lack of features, we can see addressability and statelessness: the two basic design decisions that made HTTP an improvement on its rivals, and that keep it scalable up to today’s mega-sites. Many of the features lacking in HTTP 0.9 have since turned out to be unnecessary or counterproductive.Adding them back actually cripples the Web. Most of the rest were implemented in the 1.0 and 1.1 revisions of the protocol.
 
HTTP的第一个版本（指0.9），被聪明地伪装成功能简陋，我们可以看到可寻址性和无状态性，这两个基本的设计策略使得HTTP优于它的竞争对手，并使它在可扩展性方面能够适应今天的百万级站点。HTTP0.9中缺少的很多功能，大多数都在1.0和1.1版本中被实现，后来反而成为不必要的或者反生产力的，加上它们实际削弱了Web。

 
作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？

 

最近为了升级7wxAop框架(自用+开源)的后端基础结构，花了很多时间做技术准备，以上是调查REST时的疑问，请这方面有经验的同学参与讨论解惑。

REST话题没有专版，不知道该发何处，先放在人比较多的JAVA版:-)。

这其实是你对REST的误解，其实资源可以理解为任何东西，与有多少个数据对象没有任何关系，只要它可以展现成xml或者json等平台无关的数据就可以了。

老大，能不能一条一条讨论？

你已经看出来我理解能力差了，这么回答我岂不是更晕?

我知道“资源”是可以指各种东西，但REST论文中的Resource确实是指页面、图片之类的HTML相关文档，我关心的是这个概念是什么时候、被什么人扩大为"各种东西"?

 

,那篇论文看得有点晕，可以看看江南白衣的博客有篇REST的文章或者是AJAX模式与最佳实践比较好理解一点。

我的看法:

1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的

2.Cacheable针对的是那些公开的资源.

3.扩充动词是必要的

4. 原来面对的问题在REST中一样会面对

 

a.应该违反了REST

b.也违反

c.没有规定一定要用什么方法,REST是一种style,不是specification

d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET.

谢谢推荐，我在je上也搜过rest。这些问题是看过很多rest资料后还存在的，所以希望有具体回答。

1.肯定要违背REST服务器Stateless 原则
   可以考虑SNA架构，服务器端实现无状态不是很难，JE里面有很多讨论
2.确实是如你所言
3.这类应用面对的“数据对象”和REST中的“Resource”应该是不同的
   不用死扣概念，按照我的理解，只要需要展现的数据可以使用XML来描述（或者其它的格式，但是XML更加通用），数据库里面的所有数据都可以表现成XML把？
4.只使用POST/GET可以实现RESTful，rails就是借助method="delete/put"参数来模拟实现的
5.REST只是一种HTTP协议下实现远程数据交换的概念，具体实现就多种多样了，在一般都应用里面最好是选择性的使用REST，在说了在java里面也没有rails那样完美的实现方案！
以上只是我个人的理解，请大家喷一喷有什么不对的地方！

<p>

这么说，企业应用程序要保持RESTful的纯洁性是很难的了。。。

对于回复1，几年前做7wxAop(on IBM Websphere) 与 domino 集成的SSO时，用过HTTP的Basic验证机制，有点忘了。。。刚才翻了一下7wxAop后端代码：

	/*外置用户认证时取用户信息,IBM WebSphere单点登陆、SAP WAS单点登陆 */
	String ssoType = DeepConfig.ssoType;
	String curUserId = getUserID(req);
	if(ssoType != null && ssoType.length()>0 && curUserId==null){//当前用户未本地登陆且配置为单点登陆时
		String userID = null;
		if("IBM".equalsIgnoreCase(ssoType)){//Get IBM SSO UID
			if("Basic".equals(req.getAuthType()))
				userID = req.getRemoteUser();

		}else if("SAP".equalsIgnoreCase(ssoType)){//Get SAP SSO UID

...

HTTP的验证机制某种程度上确实可以代替基于cookies的会话，看来需要再仔细看看HTTP spec 和相关的 rfc2617。谢谢你的提醒。

 

老实说我也没有仔细研究过Fielding的论文，我对于REST的认识来自于Rails框架的REST功能。所以就Rails的REST来说：



反正Rails的REST是可以携带Cookie的。



对于Rails的REST来说，proxy cache并不是其主要目的，即便不REST，一样可以cache，有了REST，cache也没啥区别。



就Rails的REST来说吧，其实不是4个动词，而是4类动词，你可以用GET来定义很多动词，也可以用POST/PUT/DELETE定义很多动词。这些动词的定义都是通过routes.rb来实现的，动词的属性只有这四类，但是你可以用这四类属性定义n多的动词出来。



a、起码不违背Rails的REST
b、这个肯定不违背，统计次数不是帖子的状态
c、Rails就是用POST模拟PUT和DELETE的，所以是肯定的
d、他应该指的是HTTP/1.1协议支持的那些复杂的功能，让Web变得复杂了

3、我想说的是，对于 RESTful GET ，确实如你所说，什么数据都可以，因为对GET来说返回的数据都是一个整体；但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂。

5、“选择性的使用REST”，，，很赞同你这句话。

不了解rails，所以不理解“在java里面也没有rails那样完美的实现方案”？是做不到，还是没人做？