RESTful架构深入分析

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>

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>

以上是获得一个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"
/>

注意，有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修改过]