Web Service实践之REST vs RPC

r囧r小猫 2022-04-11 12:45 153阅读 0赞

本博客所有内容采用[Creative Commons Licenses][]许可使用. 引用本内容时，请保留[朱涛][Link 1],[出处][Link 2]，并且 非商业。

**一.摘要**

Web Service 已经不再新鲜, 而随后的 SOA, Cloud Computing 也不断出现, 直到百度也提出了自己的 框计算, 我们尚且不管这些时髦的名词背后所蕴藏的实际的技术创新有多少, 但是他们终究是逃不出一点, 即 如何解决访问服务的问题, 而此处的服务通常不在本地而是在 遥远的你不知道的美国或者印度。

本文想阐述标题中提到的两种解决远程服务访问的方法,优缺点及其一些实际的建议等。

**二.引入**

我们每天都在使用浏览器来上网冲浪, 在查找自己需要的资源, HTTP协议自然是我们使用的最多的 一种, 我们尽情地享受着这种信息高速路的快感,却没有试图去了解我们是如何获得这些资源的? 它是一种什么样的设计理念?

我们也偶尔会使用 Gtalk来和自己的同事或者朋友来聊天, 我们在给朋友提供资源(信息)的同时 也获取着朋友的资源(信息), 我们是否可曾想过, 这种交流背后又是一种什么过程呢?

在这互联网的时代,只要牵扯到获得非本地的资源, 都会面临一个问题：

如何访问服务呢?

让我们先看看什么是[Web Service][]。

**三.Web Service**

Web Service 也提出了好久了，那么究竟什么是 Web Service?

简单地说, 也就是服务器如何向客户端提供服务。常用的方法有：

1.RPC 所谓的远程过程调用 (面向方法)

2.SOA 所谓的面向服务的架构(面向消息)

3.REST 所谓的 Representational state transfer (面向资源)

SOA 是前几年炒的很火的一个词, 不亚于当前的 Cloud Computing , 如果说 RPC 是基于方法调用(method),那么 SOA 则是基于 消息, 基于方法调用通常会与特定的程序语言 耦合起来,而后者则与具体的实现语言无关, 所以在一定程度上得到大公司的支持。

**四.RPC**

RPC 即远程过程调用, 很简单的概念, 像调用本地服务(方法)一样调用服务器的服务(方法)，通常的实现有 XML-RPC , JSON-RPC , 通信方式基本相同, 所不同的只是传输数据的格式。(如果你已经习惯于XML繁重的尖括号,你不妨可以尝试下更加轻型,高效,传输效率高的 JSON.)

一个简单的通信过程通常为：

Request

<?xml version="1.0"?>
    <methodCall>
      <methodName>member.get_username_by_id</methodName>
      <params>
        <param>
            <value><i4>1</i4></value>
        </param>
      </params>
    </methodCall>

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 的。

这里提到的条件包括：

1.C/S结构 (这是Internet服务的一个基本特征)

2.无状态 (很熟悉吧,呵呵)

3.可以cache (想起了浏览器?)

4.分层系统 (想起了无数的架构?)

5.统一的接口 (如果这是可能的,程序员有福了)

6.code on demand(可选, 其实是一种扩展性的要求)

看了这几个特征后,你想起了什么?你可能会破口而出：HTTP。我答: You got it!

HTTP是WWW的最核心的协议, 它将简单的分布于世界各个角落的资源都统一起来, 统一的地址, 简单的方法, 和一定数量的表达方式.(你可能对这三点描述很模糊,请go ahead)。

REST 的三个要素是 唯一的资源标识, 简单的方法 (此处的方法是个抽象的概念), 一定的表达方式。看下图：REST的三角架构(摘自[Restful User Experience][])

![42f83e22-4fac-3b5a-ac10-14c84290450b.jpg][]

REST是以 资源 为中心, 名词即资源的地址, 动词即施加于名词上的一些有限操作, 表达是对各种资源形态的抽象。

以HTTP为例, 名词即为URI(统一资源标识), 动词包括POST, GET, PUT, DELETE等(还有其它不常用的2个,所以 整个动词集合是有限的), 资源的形态（如text, html, image, pdf等）。

**六.RPC与REST的区别**

如果你想只记住一点,那么就请记住 RPC是以动词为中心的, REST是以名词为中心的, 此处的 动词指的是一些方法, 名词是指资源。

你会发现,以动词为中心,意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现 相应的动词(方法), 客户端需要知道这个新的动词并进行调用。

而以名词为中心, 假使我请求的是 hostname/friends/, 无论这个URI对应的服务怎么变化,客户端是无需 关注和更新的,而这种变化对客户端也是透明的。

至于其它的区别,如对实现语言的依赖, 耦合性等,这些都是上面提到的这个根本区别所衍生的。

让我们回到引入部分的2个问题. 当你每天使用HTTP冲浪时,你都在使用 REST 与远程的服务器进行亲密接触，当你使用Gtalk和同事朋友沟通时,你则是在享受着 RPC 的便利。

推荐阅读 [Restful User Experience][] (这个slide是个人认为解释的最好的) 还有 [ReST vs SOA(P)][ReST vs SOA_P]。

**1.如何选择?**

通常如果我们是客户端,我们基本上是没有选择的权利的, 服务提供商通常只有一种架构的服务.例如facebook, 人人 网开放的API(使用的是 REST)。

但是倘若我们有幸设计和实现自己的 Web Service 我们该如何选择呢?

根据笔者自己的经验和心得, 建议 能够使用REST就尽量使用REST, 主要基于下面几个考虑：

a.扩展性

b.松耦合(意味着,不用强制要求客户端去更新相应的代码)

c.客户端实现语言无关

d.性能

e.安全性(例如HTTPS)

当然上述的几点也并非 RPC 都不满足,不过相对而言, REST 更加清晰和简洁, 再辅以 JSON 相应的服务会在性能和稳定性(简单通常意味着robust)方面有很大的提高。

**2.一个自己的项目例子**

我们公司正在做一个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的可能性不大。

**3.结论**

无论是基于动词、名词或者消息，这些都是为我们提供一个稳定,可靠,安全,易扩展的服务为目的的。所以，如果你有机会为别的客户端提供开放API(如果你们公司是另一个facebook, twitter),你不妨多考虑下基于 你的平台的开发者。

文章来源：[http://www.cnblogs.com/Tim-Yi/archive/2011/11/03/2234230.html][http_www.cnblogs.com_Tim-Yi_archive_2011_11_03_2234230.html]

[Creative Commons Licenses]: https://creativecommons.org/licenses/
[Link 1]: https://sites.google.com/site/towerjoo/
[Link 2]: http://www.cnblogs.com/mindsbook
[Web Service]: https://en.wikipedia.org/wiki/Web_service
[Restful User Experience]: http://www.slideshare.net/trilancer/restful-user-experience-1421793
[42f83e22-4fac-3b5a-ac10-14c84290450b.jpg]: /images/20220411/8d8997c1246f4d119181fb0d5da761b9.png
[ReST vs SOA_P]: http://www.slideshare.net/ozten/rest-vs-soap-yawn
[http_www.cnblogs.com_Tim-Yi_archive_2011_11_03_2234230.html]: http://www.cnblogs.com/Tim-Yi/archive/2011/11/03/2234230.html