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。
这里有两种算法达到不同的效果
-
- 简单算法,以页面返回内容的HashCode作为ETag,服务端依然进行计算,得出最后的页面,并进行Hash比较,如果与客户的ETag相同则不返回304,这种算法简单,主要节约了数据传输时间。
- 复杂算法,为页面设置版本号,以版本号作为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 。