Webservice学习笔记五,Web Service实践之REST vs RPC
原文:http://www.congci.com/item/299
摘要Web Service ?已经不再新鲜,而随后的?SOA,?Cloud Computing ?也不断出现,直到百度也 提出了自己的?框计算,我们尚且不管这些时髦的名词背后所蕴藏的实际的技术创新有多少,但是他们终究是逃不出一点,即?如何解决访问服务的问题,而此处的服务通常不在本地而是在遥远的你不知道的美国或者印度. 本文想阐述标题中提到的两种解决远程服务访问的方法,优缺点及其一些实际的建议等. Contents
引入我们每天都在使用浏览器来上网冲浪,在查找自己需要的资源,HTTP协议自然是我们使用的最多的 一种,我们尽情地享受着这种信息高速路的快感,却没有试图去了解我们是如何获得这些资源的? 它是一种什么样的设计理念? 我们也偶尔会使用 Gtalk来和自己的同事或者朋友来聊天,我们在给朋友提供资源(信息)的同时 也获取着朋友的资源(信息),我们是否可曾想过,这种交流背后又是一种什么过程呢? 在这互联网的时代,只要牵扯到获得非本地的资源,都会面临一个问题: 如何访问服务呢? 让我们先看看什么是?Web Service .
Web ServiceWeb Service ?也提出了好久了,那么究竟什么是?Web Service ?? 简单地说,也就是服务器如何向客户端提供服务. 常用的方法有:
SOA ?是前几年炒的很火的一个词,不亚于当前的?Cloud Computing ?,如果说?RPC ?是基于方法调用(method),那么?SOA ?则是基于?消息,基于方法调用通常会与特定的程序语言 耦合起来,而后者则与具体的实现语言无关,所以在一定程度上得到大公司的支持. 本文不会在?SOA ?上着笔过多,主要是因为笔者本人对这个没有多少研究,怕误导读者. 另笔者最近对?RPC ?和?REST ?方式的原理和实现有一些研究,所以本文会主要集中在?RPC ?和REST .
RPCRPC ?即远程过程调用,很简单的概念,?像调用本地服务(方法)一样调用服务器的服务(方法) .通常的实现有?XML-RPC ?,?JSON-RPC ?,通信方式基本相同,所不同的只是传输数据的格式. (如果你已经习惯于XML繁重的尖括号,你不妨可以尝试下更加轻型,高效,传输效率高的?JSON .) 一个简单的通信过程通常为: Request <?xml version="1.0"?>
<methodCall>
<methodName>member.get_username_by_id</methodName>
<params>
<param>
<value><string>1</string></value>
Response <?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><string>Zhu Tao</string></value>
</param>
</params>
</methodResponse>
向服务器发送一个过程调用的方法及其参数,得到服务器返回的方法执行的结果. 在?XML-RPC ?之后又有了更加强大的?SOAP ?,用于一些比较复杂的系统之上.
REST终于我们来看?REST ?了,呵呵,这个是我目前比较喜欢的一个远程通信方法(架构). REST ?不是一种协议,它是一种架构,一种?Web Service ?能够如果满足?REST ?的几个条件,通常就称这个系统是?Restful ?的. 这里提到的条件包括:
看了这几个特征后,你想起了什么? 你可能会破口而出:?HTTP . 我答:?You got it!
HTTP是WWW的最核心的协议,它将简单的分布于世界各个角落的资源都统一起来,统一的地址,简单的方法,和一定数量的表达方式.(你可能对这三点描述很模糊,请go ahead). REST ?的三个要素是?唯一的资源标识,?简单的方法 ?(此处的方法是个抽象的概念),?一定的表达方式 . 看下图: 图一. REST的三角架构(摘自?Restful User Experience ?) ?
REST ?是以?资源 ?为中心,名词即资源的地址,动词即施加于名词上的一些有限操作,表达是对各种资源形态的抽象. 以HTTP为例,名词即为URI(统一资源标识),动词包括POST,GET,PUT,DELETE等(还有其它不常用的2个,所以 整个动词集合是有限的),资源的形态(如text,html,image,pdf等)
RPC与REST的区别如果你想只记住一点,那么就请记住 RPC是以动词为中心的,REST是以名词为中心的,此处的动词指的是一些方法,名词是指资源.
如何选择?通常如果我们是客户端,我们基本上是没有选择的权利的,服务提供商通常只有一种架构的服务.例如facebook、人人网开放的API(使用的是?REST ?). 但是倘若我们有幸设计和实现自己的?Web Service ?我们该如何选择呢? 根据笔者自己的经验和心得,建议?能够使用REST就尽量使用REST,主要基于下面几个考虑:
当然上述的几点也并非?RPC ?都不满足,不过相对而言,?REST?更加清晰和简洁,再辅以?JSON?相应的服务会在性能和稳定性(简单通常意味着robust)方面有很大的提高. 一个自己的项目例子我们公司正在做一个social game的项目,我负责整个系统的后端架构和通信等,所以仔细地学习和研究了 facebook/人人网开放的API,由于facebook(人人网完全拷贝facebook)使用的是REST?的架构,所以即使facebook本身是PHP开发的,这也不妨碍我们使用python来开发,还有更多的PHP,Java,.net,Perl等客户端API封装. (当然人人网是使用Java开发的,我们也使用python). 于是在想,倘若facebook的架构使用的不是?REST ?,会有这样的灵活性吗? 如果使用的是?RPC ?可能 目前我们的日子不会好过,甚至我们的项目都不可能立项! 另外,因为我们的前端使用的是flash,与后端的python通信采用的是?djangoamf ?,有意思的是,如果你了解 flash,你会知道AMF是一种二进制的flash数据交互协议,而?它是基于RPC ?! 当然这正如我上面说的,某些架构不是我们能够选择的,所以使用?RPC ?的结果是如果我们想开放我们游戏的API(假如我们的游戏足够火,有朋友想基于我们的游戏开发周边应用),这就变得很艰难了.但是目前来看,我们开放API的可能性不大. 结论无论是基于?动词,?名词 ?或者?消息,这些都是为我们提供一个稳定,可靠,安全,易扩展的服务为目的的,所以,如果你有机会为别的客户端提供开放API(如果你们公司是另一个facebook,twitter),你不妨多考虑下基于 你的平台的开发者们,别让他们的日子不好过啊(同是程序员,相煎何太急?呵呵). (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |