REST与RPC：选择哪种API架构风格？

1.1 RPC

RPC&＃xff08;Remote Procedure Call&＃xff09;—远程过程调用&＃xff0c;它是一种通过网络从远程计算机程序上请求服务&＃xff0c;而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在&＃xff0c;如TCP或UDP&＃xff0c;为通信程序之间携带信息数据。在OSI网络通信模型中&＃xff0c;RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用客户机/服务器模式。请求程序就是一个客户机&＃xff0c;而服务提供程序就是一个服务器。首先&＃xff0c;客户机调用进程发送一个有进程参数的调用信息到服务进程&＃xff0c;然后等待应答信息。在服务器端&＃xff0c;进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达&＃xff0c;服务器获得进程参数&＃xff0c;计算结果&＃xff0c;发送答复信息&＃xff0c;然后等待下一个调用信息&＃xff0c;最后&＃xff0c;客户端调用进程接收答复信息&＃xff0c;获得进程结果&＃xff0c;然后调用执行继续进行。如下图所示

1.2 REST

REST即表述性状态传递&＃xff08;英文&＃xff1a;Representational State Transfer&＃xff0c;简称REST&＃xff09;是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式&＃xff0c;可以降低开发的复杂性&＃xff0c;提高系统的可伸缩性。

在目前主流的三种Web服务交互方案中&＃xff0c;REST相比于SOAP&＃xff08;Simple Object Access protocol&＃xff0c;简单对象访问协议&＃xff09;以及XML-RPC更加简单明了&＃xff0c;无论是对URL的处理还是对Payload的编码&＃xff0c;REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准&＃xff0c;而更像是一种设计的风格。

1.2.1资源与URI

REST全称是表述性状态转移&＃xff0c;那究竟指的是什么的表述? 其实指的就是资源。任何事物&＃xff0c;只要有被引用到的必要&＃xff0c;它就是一个资源。资源可以是实体(例如手机号码)&＃xff0c;也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子&＃xff1a;

• 某用户的手机号码
• 某用户的个人信息
• 最多用户订购的GPRS套餐
• 两个产品之间的依赖关系
• 某用户可以办理的优惠套餐
• 某手机号码的潜在价值

要让一个资源可以被识别&＃xff0c;需要有个唯一标识&＃xff0c;在Web中这个唯一标识就是URI(Uniform Resource Identifier)。

URI既可以看成是资源的地址&＃xff0c;也可以看成是资源的名称。如果某些信息没有使用URI来表示&＃xff0c;那它就不能算是一个资源&＃xff0c; 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则&＃xff0c;具有自描述性&＃xff0c;需要在形式上给人以直觉上的关联。这里以github网站为例&＃xff0c;给出一些还算不错的URI&＃xff1a;

• https://github.com/git
• https://github.com/git/git
• https://github.com/git/git/blob/master/block-sha1/sha1.h
• https://github.com/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08
• https://github.com/git/git/pulls

1.2.2 统一资源接口

RESTful架构应该遵循统一接口原则&＃xff0c;统一接口包含了一组受限的预定义的操作&＃xff0c;不论什么样的资源&＃xff0c;都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET&＃xff0c;PUT和POST&＃xff0c;并遵循这些方法的语义。

如果按照HTTP方法的语义来暴露资源&＃xff0c;那么接口将会拥有安全性和幂等性的特性&＃xff0c;例如GET和HEAD请求都是安全的&＃xff0c; 无论请求多少次&＃xff0c;都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的&＃xff0c;无论对资源操作多少次&＃xff0c; 结果总是一样的&＃xff0c;后面的请求并不会产生比第一次更多的影响。

统一资源接口要求使用标准的HTTP方法对资源进行操作&＃xff0c;所以URI只应该来表示资源的名称&＃xff0c;而不应该包括资源的操作。

通俗来说&＃xff0c;URI不应该使用动作来描述。例如&＃xff0c;下面是一些不符合统一接口要求的URI:

• GET /getUser/1
• POST /createUser
• PUT /updateUser/1
• DELETE /deleteUser/1

REST采用标准HTTP的相应代码&＃xff0c;HTTP的响应代码可用于应付不同场合&＃xff0c;正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。

1.2.3 资源的表述

客户端通过HTTP方法可以获取资源&＃xff0c;是吧? 不&＃xff0c;确切的说&＃xff0c;客户端获取的只是资源的表述而已。 资源在外界的具体呈现&＃xff0c;可以有多种表述(或成为表现、表示)形式&＃xff0c;在客户端和服务端之间传送的也是资源的表述&＃xff0c;而不是资源本身。 例如文本资源可以采用html、xml、json等格式&＃xff0c;图片可以使用PNG或JPG展现出来。

1.2.4 资源的链接

我们知道REST是使用标准的HTTP方法来操作资源的&＃xff0c;但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。
这种反模式忽略了一个核心概念&＃xff1a;”超媒体即应用状态引擎&＃xff08;hypermedia as the engine of application state&＃xff09;”。 超媒体是什么?
当你浏览Web网页时&＃xff0c;从一个连接跳到一个页面&＃xff0c;再从另一个连接跳到另外一个页面&＃xff0c;就是利用了超媒体的概念&＃xff1a;把一个个把资源链接起来.
要达到这个目的&＃xff0c;就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中&＃xff0c;作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。
下面展示的是github获取某个组织下的项目列表的请求&＃xff0c;可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边&＃xff0c;用url来链接项目所有者和项目地址。

1.2.5 状态的转移

有了上面的铺垫&＃xff0c;再讨论REST里边的状态转移就会很容易理解了。

不过&＃xff0c;我们先来讨论一下REST原则中的无状态通信原则。初看一下&＃xff0c;好像自相矛盾了&＃xff0c;既然无状态&＃xff0c;何来状态转移一说?

其实&＃xff0c;这里说的无状态通信原则&＃xff0c;并不是说客户端应用不能有状态&＃xff0c;而是指服务端不应该保存客户端状态。

“会话”状态不是作为资源状态保存在服务端的&＃xff0c;而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。

这些类似”下一页”之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。

REST需要满足如下约束&＃xff1a;

• 客户端-服务器
• 无状态
• 可缓存
• 分层系统
• 按需代码&＃xff08;可选&＃xff09;
• 统一的接口

一般来讲&＃xff0c;RPC是以动词为中心的, REST是以名词为中心的, 此处的 动词指的是一些方法, 名词是指资源.

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

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

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