轻的，谁都会写的Service方案--REST与JSON

1.REST

1.1 缘起

    N年前，一说到跨平台的服务方案，大牛们就想到"Socket Server"，小兵们就一直退，退到会议室的墙角。
    几年前，一说到跨平台的服务方案，连客户都会想到"Web Service"。
    现在，是个人都可以，在几分钟里，使用REST风格把一个服务的客户端和服务端写出来。

1.2 初见 

    REST首先是一个词，然后代表了一种服务提供模式。嗯，圣贤说，任意服务协议，都可以拆成传输协议，服务模式，数据格式三维表达，那REST就是依赖http作为传输机制，request-reponse模式，数据是预先协商好的任意格式。

    结果，任何语言的客户端，随便用一个http库访问某个URL，将请求信息写成XML或JSON或纯字符串，放在POST实体中。服务端也任意的实现一个servlet甚至jsp/asp/php，接收客户端发过来的请求，返回XML/JSON/字符串的结果就完了。

   So Easy，心里是不是立刻就想到了实现的方式。Java里用Apache的HttpClient  发送一个POST请求。

HttpClient httpClient = new HttpClient();
EntityEnclosingMethod method = new PostMethod(url); method.setRequestBody(fooXml);
method.setRequestHeader("Content-type","application/xml; charset=utf8"); 
httpClient.executeMethod(method); 
String body = method.getResponseBodyAsString(); 

 

    另外一个XML/JSON的操作库，严重推荐codehaus的xstream ，很漂亮的在xml/json和java对象间转换。比其他重型的xml binding方案便捷得多，下面是xml与java对象互转的代码。

Xstream  xs = new Xstream(); 
String xml = xs.toXML(foo);
Foo foo = (Foo)xs.FromXML(xml);  

 

    .Net下面就更简单，http库和xml库都自带了。
     这是个最吸引人的地方，就是REST里，写服务不再是一个框架级的事情，不再需要配置文件和回调函数，只要懂几个API，甚至API都不要，白手DIY出服务来。InfoQ的这篇文章不错：Simple JAVA and .NET SOA interoperability 

  1.3 主义

    罗喧说，REST是面向消息(资源)的简单交互逐步替代RPC。真正的REST有如下的主张：

• 为所有"事物"定义一个互联网上的ID，并连接起来。一个很不错的主意。

  <order self='http://example.com/customers/1234' >
  	<amount>23</amount>
  	<product ref='http://example.com/products/4554' />
  </order>

• 定义PUT/GET/DELETE/POST的标准方法前三个方法具有幂等性，这样互联网应用间就无需特定API。
  对像"审批"这样服务，就缺乏直接表达能力，只能搞一个叫审批业务的资源，POST代表发起审批，DELETE代表撤销，虽然别扭，但总是过关了。
• 资源的多重表述。
  客户端发起诸如application/vnd.mycompany.customer+xml、Accept: text/x-vcard 的请求，服务端据此将同一资源渲染成不同的返回。
• 无状态通信。
  状态要么被放入资源状态中，要么保存在客户端上。这样客户不依赖于服务端实例，服务端可以任意扩展或重启。
• 天然的利用HTTP的压缩与缓存机制
  Http的压缩机制，只要client说自己accept encoding:gzip，server就可以压缩传输。
  使用ETags减少Web应用带宽和负载(InfoQ) 
  
  ETag的原理很简单，就是服务器在Response时可以带一个ETag，下次用户的Header可以带一个If-None-Match:ETag's value，服务器判断ETag，如果未发生修改，返回HTTP/1.x 304 Not Modified。
  这里有两种算法达到不同的效果
  1. 简单算法，以页面返回内容的HashCode作为ETag，服务端依然进行计算，得出最后的页面，并进行Hash比较，如果与客户的ETag相同则不返回304，这种算法简单，主要节约了数据传输时间。
  2. 复杂算法，为页面设置版本号，以版本号作为ETag。在服务端设置资源改变所影响的页面，比如用Hibernate的Listener，在数据增删改时，增加所有可能受影响页面的版本号。这种算法相对复杂，但同时节约了服务器计算时间与传输时间。 
     

  1.4 代价

    当然，REST简单也有简单的代价，比如缺乏了事务、可靠性、WS-Address、UDDI等机制。不过这些机制在正统的WebService世界里使用的也不多。对于那些没有使用任何附加机制的纯WebService，都可以考虑用REST编写，或者像DIY事务 一样自己设计协议。

   另外需要客户自解释Payload，或是依靠Server方提供的SDK，而不能从直接WSDL生成DTO，WADL 尚无定论。

   最后，REST除了作为Service方案，还可以作为Web应用MVC方案，比如Cetia4（https://cetia4.dev.java.net/ ）就叫板替代传统的MVC框架，不过我觉得又搞一堆框架后，简单就渐渐失去意义了，加上最近都不搞Web应用，花半天看完它的教程文档后，不再关注。

2.JSON

   JSON简介(dev2dev) 。如果有大数据量的传输，JSON(JavaScript Object Notation) ，是对XML尤其是SOAP中复杂XML的简化。如：

   {"product":{"name":"Banana","id":"123","price":"23.0"}}

 

     每种语言都有N种JSON解释器 。XStream也用Jettison 做driver，支持Java对象与JSON的序列化，建立XStream对象时将参数改为Jettision就可以了，其他操作与XML一样，见JSON Tutorial 

    XStream xstream = new XStream(new JettisonMappedXmlDriver());

    无独有偶，Apache CXF（XFire)也用Jettison支持Web Service使用JSON格式，详见它的JSON Support 。

 

参考资料：

Architectural Styles and the Design of Network-based Software Architectures(中文版) REST起源的论文,dlee翻译。

《RESTful Web Services》  2007

深入浅出REST(InfoQ) 

Building scalable, reliable, secure, RESTful services(JavaZone 2007) 

评论

7 楼 galaxystar 2007-08-09  

ajax+rest挺合适做产品的.

6 楼 yongyuan.jiang 2007-08-09  

通过http直接获得服务非常好，跨平台，跨项目。 <br />
当然也不是万能的，对于局域网内的机器便无法适用。

5 楼 steeven 2007-08-07  

json.org里面有几个很搞笑的方法：optXxx()...
getXxx()则抛异常。

json是个好东西，rest应该就是个url约定吧，有必要小题大做吗？

4 楼 wutao8818 2007-07-09  

被json org 的 api 愚弄过,后来发现不是那么回事。没我想的美

3 楼 dwangel 2007-06-23  

json 的网站 http://json.org/

开始研究ajax中……

2 楼 fins 2007-06-21  

<p>我也正要问2楼问的那个问题 呵呵 </p>
<p>希望有人可以写一篇java下json组件/类库的总结评测文章.</p>
<p>&nbsp;</p>

1 楼 totobacoo 2007-06-21  

为什么不提 org.json 或者 json-lib， 也很好用啊