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修改过]