RESTful架构深入分析

09-08-04 banq
Atom Publishing Protocol原来很适合RESful,它有清晰的Collection/element边界。特别是它的Discovery 和next就很有RESTful。

Discovery

客户端向服务器端发出GET Introspection,得到一个Introspection Doc,类似内容如下:

<service>
   <workspace title="Side Bar Blog">
        <collection contents="entries" title="Entries" href="http://example.org/reilly/feed" />
       <collection contents="http://example.net/booklist" title="Books" href="http://example.org/reilly/books"/>
</service>
<p>

workspace可以看成是不同领域,有两个List集合。这个Discovery很类似SOA中喊叫的服务发现哦。

List

客户端从http://example.org/reilly/feed获得Entry集合,结果如下:

<feed xmlns="http://www.w3.org/2005/Atom" xml:base="http://example.org/blog/entries">
<id>http://example.org/blog/entries</id>
<title>My Blog Entries</title>
<updated>2006-08-12T13:40:03Z</updated>
<link rel="self" href="/blog/entries" />
<link href="http://blog.example.org" />
<entry>
   <id>tag:example.org,2006:/blog/entries/1</id>
   <title>Atom-Powered Robots Run Amok</title>
   <link href="http://example.org/2003/12/13/atom03"/>
   <link rel="edit" href="http://example.org/blog/entries/1" />
   <updated>2006-08-12T13:40:03Z</updated>
   <author><name>James</name></author>
   <summary>Some text.</summary>
</entry>
<entry> ...
</entry> ...
</feed>
<p>

以上是获得一个Entry List的结果,如果存在多页,多个页面,可以返回如下:

<feed xmlns="http://www.w3.org/2005/Atom" xml:base="http://example.org/blog/entries?page2">
   <link rel="next" href="entries?page3" />
    <link rel="previous" href="entries?page1"
/>
<p>

注意,有next和previous前后页之分,这个很有创意,就有导航作用了,也有过程流程控制作用,SOA中强调的复杂的流程控制是不是就可以用这个简单next标签来实现?事情原来可以这样简单的。

APP缺点

ATOM只适合RIA,是XML的。浏览器的Javascript就不适合。有一篇APP已经失败的文章:

http://bitworking.org/news/425/atompub-is-a-failure

JSON Restful

如何实现一个跨客户端类型(无论是Java客户端还是浏览器)的Restful的通讯呢?

使用JSON,模拟ATOM.JSON Restful最好,既适合浏览器 也适合Java客户端,跨客户端

http://bitworking.org/news/restful_json

可以实现List的JSON结果如下:

{

"members":

[

{ "href": "1" },

{ "href": "2" },

{ "href": "3" },

....

{ "href": "N" },

],

"next": "http://example/coll?page=2"

}]

只可惜,RestLet和jersey两个号称RESTful的框架,其实只是一个Web服务的变种,而RESTful是一种架构,就如同SOA是一种架构一样,我们能把Web服务ws-*和SOA并列起来吗?所以,从基本逻辑上,这两个RESTful开源项目就是错误的,挂羊头卖狗肉。

将REST变种为Web服务,主要还是受害于RESTful就是CRUD一种观点,其实,CRUD不适合于REST,原因可以从SOA角度来理解,CRUD服务是SOA的反模式:

1.限制了服务的整体概念——没有业务逻辑。

2.暴露了内部的数据库结构,或者数据接口,而不是仔细考虑后的接口。

3.鼓励直通服务和数据的做法。

4.建立的是块(Blob)服务(数据源)

5.鼓励细小的多重服务(为块服务定义多重接口),而忽略了分布式计算的若干谬误。

6.仅仅是“批着羊皮”的C-S结构。(就是指那些RESTful Web Services框架jersey RestLet)

参考:

http://www.infoq.com/cn/news/2009/08/CRUDREST

[该贴被banq于2009-08-04 18:10修改过]

[该贴被banq于2009-08-04 18:11修改过]

         

2
bloodrate
2009-08-05 10:09
没看出jersey怎么REST,其仅仅对于请求方式进行了封装,http://localhost:8080/book/11可以轻松影射到pojo得到处理,而对返回的超文本没有限定,如何才能保证超文本驱动?如果就是http://localhost:8080/book/11那webwork也能做啊

banq
2009-08-07 11:31
REST真相

http://www.jdon.com/jivejdon/thread/36743.html

猜你喜欢