|
精华帖 (0) :: 良好帖 (18) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-05-06
leebai 写道
<p> quaff 写道
我的看法: 1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的 2.Cacheable针对的是那些公开的资源. 3.扩充动词是必要的 4. 原来面对的问题在REST中一样会面对 a.应该违反了REST b.也违反 c.没有规定一定要用什么方法,REST是一种style,不是specification d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET.
这么说，企业应用程序要保持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。谢谢你的提醒。
其实我说的不是Http的Basic验证,我的意思是在http header里面带上用户名密码或者token |
| 返回顶楼 | |
|
发表时间：2008-05-06
leebai 写道
<p> quaff 写道
我的看法: 1.在http header里面带上授权信息,一般web service也是在soap头里面加,还有GData api好像也是这样的 2.Cacheable针对的是那些公开的资源. 3.扩充动词是必要的 4. 原来面对的问题在REST中一样会面对 a.应该违反了REST b.也违反 c.没有规定一定要用什么方法,REST是一种style,不是specification d.大部分情况下都是用GET去模拟其他动作的,因为浏览器的限制,比如连接只能是GET.
这么说，企业应用程序要保持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。谢谢你的提醒。
HTTP Basic验证也无非就是HTTP Header里面夹带了私货，这和Cookie是一样的，Cookie也是在HTTP Header里面的，这两者没有任何区别。 另外Rails的REST实现当中，就是支持使用HTTP Basic验证的，你可以看看ActiveResource，实现起来特别简单。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
引用 但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂
不管是POST/PUT/DELETE还是什么操作，只要你定义一个url能够唯一标识你将要操作的数据，后台随便你做多少操作都没有什么关系。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
leebai 写道 rain2005 写道 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那样完美的实现方案！ 以上只是我个人的理解，请大家喷一喷有什么不对的地方！ 3、我想说的是，对于 RESTful GET ，确实如你所说，什么数据都可以，因为对GET来说返回的数据都是一个整体；但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂。 5、“选择性的使用REST”，，，很赞同你这句话。 不了解rails，所以不理解“在java里面也没有rails那样完美的实现方案”？是做不到，还是没人做？ struts2有restful支持,或者可以自己写ActionMapper来定制. REST跟SOAP是平等的关系,但是SOAP是一种规范,只能接受标准化的xml和返回标准化的xml,REST是一种风格,没有规定一定要怎么样,REST可以接受任何数据和返回任何数据,即使url一样,也可以智能的根据客户端的不同返回不同的数据,比如是wap浏览器的请求就返回wml,opera之类的返回html,还可以在请求的时候指定返回数据类型,目前的REST只适合做service给其他应用使用,在将来浏览器的功能足够强大了,才有REST的用武之地. |
| 返回顶楼 | |
|
发表时间：2008-05-06
robbin 写道
老实说我也没有仔细研究过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多的动词出来。 引用
另外还有几个主题之外的RESTful疑问，一并请教： a、现在很多论坛有一个功能：必须回复才能看到主帖，但看到和看不到时的访问URI是相同的，这种设计是否违背REST？ b、基本上论坛帖子都有访问次数统计，其实就是GET操作的时候改变了服务器State，应该也是违背REST吧？ c、只使用POST/GET是否也能实现RESTful？我看Fielding的论文中并没有提到必须使用PUT/DELETE。 d、在《RESTful Web Services》的序言中，作者写道： 作者的意思是不是：POST/PUT/DELETE等其实都不是RESTful的本质，只有 GET+URI 才是RESTful的核心战斗力？ a、起码不违背Rails的REST b、这个肯定不违背，统计次数不是帖子的状态 c、Rails就是用POST模拟PUT和DELETE的，所以是肯定的 d、他应该指的是HTTP/1.1协议支持的那些复杂的功能，让Web变得复杂了
既然Rails也用Cookie，那Cookie最多只是违背RESTmax:-)，不违背RESTful，俺们可以放心使用了。 Rails “其实不是4个动词，而是4类动词”，这个能接受一点，还是有点晕： 把动词分成4类，在架构上有什么特别意义？ 看来a/b是否违背rest..有争议。 谢谢站长的回复，顺便提个意见：这个发帖编辑器功能很强大，但是在BBCode编辑器 和 可视化编辑器 之间来回切换时，有时格式会乱，比如：可视编辑中修改了“引用区”之后再进BBcode，再回来就乱了。
|
| 返回顶楼 | |
|
发表时间：2008-05-06
引用 Rails “其实不是4个动词，而是4类动词”，这个能接受一点，还是有点晕： 把动词分成4类，在架构上有什么特别意义？
REST叫做“带表象的状态迁移”，动词的分类是因为这4类操作会对资源的状态带来不同的影响，造成状态的迁移。 GET 不影响资源的状态 POST 创建一个新的资源 PUT 修改一个资源的状态 DELETE 删除一个资源 所以这4类操作给资源状态迁移带来的结果是不一样的。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
robbin 写道
HTTP Basic验证也无非就是HTTP Header里面夹带了私货，这和Cookie是一样的，Cookie也是在HTTP Header里面的，这两者没有任何区别。 另外Rails的REST实现当中，就是支持使用HTTP Basic验证的，你可以看看ActiveResource，实现起来特别简单。
刚才正在看rfc2617、2616。。。HTTP 验证和Cookie对user agent 来说虽然都视头标，但实际还是有差别的：HTTP Proxy是不不理会Cookie的，但对Authorization头标却要做判断；另外session cookie是服务器颁发的，而Authorization头标一开始就来自浏览器本身，具体还在看中。。。。ActiveResource,哪天也看看。
|
| 返回顶楼 | |
|
发表时间：2008-05-06
rain2005 写道 引用 但对于RESTful POST/PUT/DELETE，数据库数据的情况要比简单资源(单一文件)要复杂
不管是POST/PUT/DELETE还是什么操作，只要你定义一个url能够唯一标识你将要操作的数据，后台随便你做多少操作都没有什么关系。 这种对REST“宽泛的约束”的解读，我能接受。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
quaff 写道
REST跟SOAP是平等的关系,但是SOAP是一种规范,只能接受标准化的xml和返回标准化的xml,REST是一种风格,没有规定一定要怎么样,REST可以接受任何数据和返回任何数据,即使url一样,也可以智能的根据客户端的不同返回不同的数据,比如是wap浏览器的请求就返回wml,opera之类的返回html,还可以在请求的时候指定返回数据类型,目前的REST只适合做service给其他应用使用,在将来浏览器的功能足够强大了,才有REST的用武之地.
我也感觉REST约束最适合的地方是：信息服务，既怎样更好地把信息“给”请求者。而对信息的管理（“改变”），"REST"应该少管。 |
| 返回顶楼 | |
|
发表时间：2008-05-06
robbin 写道
引用
Rails “其实不是4个动词，而是4类动词”，这个能接受一点，还是有点晕： 把动词分成4类，在架构上有什么特别意义？
REST叫做“带表象的状态迁移”，动词的分类是因为这4类操作会对资源的状态带来不同的影响，造成状态的迁移。 GET 不影响资源的状态 POST 创建一个新的资源 PUT 修改一个资源的状态 DELETE 删除一个资源 所以这4类操作给资源状态迁移带来的结果是不一样的。
补充：又看了一遍原文，基本确定dlee对“REST”的“T”的翻译是有问题的，Transfer就是指“状态”（或称信息、数据、资源 。。。Hypertext*）的“传输”，和HTTP的第三个T是一样的内涵，The Hypertext Transfer Protocol (HTTP)译为“超文本传输协议”，Representational State Transfer (REST)没有理由译成“表述性状态转移”。这么翻译有可能导致人们对REST的误解，以为REST描述的是“状态变更”问题。
继续补充：刚发现dlee在译文中（6.5.3小节），居然认为HTTP的传统翻译“超文本传输协议”不对。真是太荒谬了。看来经验再丰富的老手，也有糊涂的时候。 |
| 返回顶楼 | |
