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

不过虽然我赞同transport protocol就是protocol on the transport layer，即点到点的通讯，但是无论如何，传输层协议和传输协议太过混淆。

我建议可考虑 传送 传递 等词。特别是 传递，我觉得比较有中介的概念——比如火炬传递，呵呵。

我也比较倾向于将“transfer”翻译为“传输”之外的某个动词。翻译为“传输”、“超文本传输协议”，我最大的担心就是“传输”这个动词与“传输层”联系过于紧密，存在着误导的可能性，会使得读者将注意力过多地集中于HTTP消息体，而完全忽略了HTTP包头所代表的语义。SOAP在这方面已经犯过一次大错了，其设计者想当然地认为HTTP只是一种能够穿越防火墙的传输协议。Fielding说“HTTP并不是一种传输协议”，很大程度上就是说给SOAP设计者这些曲解HTTP的人听的。《RESTful Web Services中文版》快出来了，在这本书中，大家对SOAP所犯的错误可以看得更清楚。

TCP与HTTP的区别在于：
TCP的使用者并不需要关心TCP包头的语义，TCP包头的语义对使用者来说是完全透明的。使用者需要的仅仅是TCP所提供的透明的点对点传输。
HTTP的使用者需要关心HTTP包头的语义，HTTP包头的语义对于使用者来说并不是透明的。使用者需要的并不仅仅是HTTP所提供的透明的点对点传输。这件事情TCP已经做的非常好了，用HTTP来做这件事情是多余了，而且还增加了HTTP包头额外的负载，从网络效率的角度来看是低效的，不够精益。

我们翻译为“转移”看来还不够好，可以将“转移”改为其他的动词。

单就HTTP来说，使用“传输”之外的词也是可商量的，要考虑的是：

1、中文文档传统习惯问题。如果没有把握扭转所有的应用层“传输协议”的翻译，单改一个HTTP翻译会引起混乱。

2、如何翻译应用层协议RTP(Real-time Transport Protocol)？新的翻译应该做到“自园其说”。

我觉得要看你怎么认识”企业应用“的”资源“了，不同于通常的资源型应用（如javaeye），企业应用的资源应该是流程（那些楼主认为stateful的咚咚）。
应该业是可以作到REST的

可能非常适合受权访问的数据库性企业应用

1 权限其实非常适合用rest方式编辑访问. 不用session和cookies是完全可以的。每个用户在服务器上可以有自己的数据空间用来存放信息 权限 文件.....。 访问这个路径下的信息需要通过http的验证 http://user@password:xmlshop.com/winterwolf/权限.xml

2 sql xquery 都可以直接当做资源来调用 post数据返回结果而已. xslt css javascript也可以作为资源来灵活调用。

3 同意布老大的观点 rest方式非常适合xmldb. sql数据库虽然也通过接口支持rest方式 但是不是自然的 关系数据库本身反rest

最近仔细阅读了dlee同学热心推荐的REST论文，感觉REST真义（下称FieldingREST）我是明白了，有个观点一直没敢亮出来，下面晾晾：

RESTful这个词不知道是谁造的（源于<<RESTful Web Services>>？），其中反复强调POST/PUT/DELETE/GET四个基本操作，从这一点看，其实RESTful是对FieldingREST的歪曲，有“挂羊头卖狗肉”之嫌，P/P/D/G根本就是FieldingREST光辉躯壳下夹藏的私货。

回到本帖主题，我认为“企业应用”（本帖定义的）需遵从的FieldingREST的唯一约束是：可扩展性所需的“服务器无状态性”（也就是你第1点描述的问题），其他约束对“企业应用”都没有意义。至于RESTful，更像一个概念炒作。

 

 服务器无状态对开发分布式应用有好处。

使用put delete也是有重大意义的 。

隐含在put delete背后的深意是---- 使用文档保存数据（用xml文件）会更高效更适合web  而不是关系数据库

我认为目前native xmldb是建立rest系统的最佳方案

我不清楚xmldb，不过xml的Path与REST的资源URI路径确实很吻合，对XML数据块常见操作也不复杂，相信特定场合确实管用。

winterwolf兄做的都是些什么样的项目？ 后台数据存储主要用xmldb？