RPC与REST区别

转自：http://georid.spaces.live.com/blog/cns!BD176951AD9B69BF!741.entry 


先来了解一下： 
RPC（Remote Procedure Call）远程调用 
RPC是在客户端/服务器端（client/server）网页或软件编程中不可缺少的一种方法，client若需要对数据进行处理时，先创建一个提出问题的进程（procedure），进程采用将操作以请求的方式发送给服务器，并等待服务器端对请求做出响应并给出回复，不需要在client端去实地的进行数据处理和复杂的运算，而是将这些过程交给服务器去做，这个client端的进程只是等待，等待会有两种可能的结果：一种是由服务器端传回计算或处理的结果；二是操作超时，并未收到从服务器端发来的回复，但无论是哪一种情况发生，client端进程都算完成使命并自行结束。从编程的角度讲，打个比方，在网上购物的购物篮功能中，将选购的物品放入购物篮的操作就会使用到RPC，在客户端所表现的只是需要点击一个按钮，按钮的功能是将选定的物品放入购物篮中。这是在前台，用户可以确实的看到的操作；而在后台，在编辑这个网页的过程中，用户点击按钮的这一步，是由远程调用服务器端的相应的函数实现的。在此例中，想实现这个按钮的功能就要知道调用服务器端的添加物品的函数（也叫接口interface）的名称－－AddinBasket（）；client端发送请求给服务器，要将选定的物品放入购物篮，服务器端接到请求后，由AddinBasket函数对请求进行响应，做出处理，然后把响应结果（如，物品已放入购物篮）返回给client端。Client端接到回复后显示给用户：操作成功，物品已加入购物篮。 
那么一次RPC在计算机的内部又是如何进行的呢？“远程”调用是怎么调用实现的？ 

还拿上面的例子： 
client端，用户点击按钮后，在client本地建立一个进程A（procedure A），进程的目的是想将一本书（book）放入购物篮，进程A将这本书放入本地的内存地址中（进程A本身并不会直接去产生调用远程服务器端的请求，而是和在本地操作一样只是将数据存储到内存中，由其它进程进行处理，将结果保存到内存中），然后进入等待状态，client端的client－stub检测到进程A在内存中存储的数据后，从内存中将数据读取出来连同需要调用的函数AddinBasket函数名一起建立一个数据包发送给服务器端的 server－stub程序。 
server端，server－stub收到client－stub发送过来的数据包后，打开数据包，从里面读出数据，将数据存储到 server的内存中，server端的处理进程procedure B检测到server端由server－stub存储的数据后，调用server端的AddinBasket函数，处理数据，并将结果存入server端的内存，通知server－stub数据处理完毕，server－stub从内存中读取出处理结果，制作一个数据包作为client端请求的回复发送给 client－stub。自此server端的运行完毕。
client端，client－stub接收到数据包，从中读取出处理结果的数据，保存到client端的内存中并通知进程A数据处理完毕。进程A从内存中读取结果。这样一次远程调用彻底结束。在这个过程中，client端的进程A以及server端的进程B都不知道他们要进行的是一个远程的调用或请求，而是一直当作本地的操作一样，从各自本地的内存中读取数据，而client－stub和server－stub是实现这个远程调用的具体实施者。这种客户端向服务器端发送请求，由服务器相应处理传回结果的方法被称为RPC（远程调用）。 
因为需要调用服务器端的接口函数就需要了解服务器端究竟提供了什么样的接口，接口的实现方法是什么，函数的参数是什么类型的，这些信息都会写在服务器端的函数文档中，如上面的购物篮功能涉及的函数不光有：AddinBasket()还应该包括，RemovefromBasket(),ClearBasket(),getBasketItem(),purchasBasket()等等这些，这些也就是相对于客户的“从购物篮中删除物品”，“清空购物篮”，“获得购物篮中的物品列表”，“为购物篮内物品付款”的这些具体的操作的响应函数，编程人员在编写页面的代码时需要透彻的理解各个函数的调用方法，以及相互之间的逻辑关系。这里的逻辑关系是指如例中，当购物篮内是空的时，从购物篮中删除物品的按钮应该是不允许操作状态的。这一系列的函数的理解都给编程增添了复杂度，而且服务器端在正式运行中要处理所有的用户请求，而这些请求的功能是很烦琐的，这给服务器端无形中创造了很多的工作量，而REST在这一点上是很精简有效的。 

现在我们来看： 
REST（Representational Status Transfer） 
必须承认的是大部分的REST的实现中使用了RPC的机制，它也有client端和server端，所不同于RPC的是，它的响应函数简单来讲就是get函数和post函数，对于上面使用的购物篮问题中使用REST方法实现的化，只需要两个函数getBasket和PostBasket，getBasket 函数是将服务器端当前的购物篮状态获取下来，client端想对购物篮中的物品做出操作的话，比如添加一本书，或将已经有的物品取出购物篮，直接修改修改购物篮中的物品，最后将一个新的购物篮内物品的状态（status）用postBasket方法发送给服务器。这就是REST的中心原理，即：下载服务器端的当前状态，修改之后将最终用户所期待的状态发送给服务器，服务器按照客户的期待进行修改。而不同于RPC的也就是响应函数没有那么多的，复杂的逻辑关系，函数也减少了很多，只是get和post两个。从而给服务器减少了工作量而且在逻辑上也是符合的。表面上看来REST比RPC是要先进的，但是 REST的缺点在于，这种只有get和post的逻辑并不是永远有效的，并不是对一切问题都是万能的，举个例子来说：两个用户A和B使用同一个账户在网上商店购物，他们都从服务器端获得了当前购物篮中的状态，用户A向购物篮中添加了一本书，用户B在购物篮中添加了一辆自行车，随后A先向购物篮状态上传给服务器，此时服务器中购物篮里多出了一本书，此时B也把他的购物篮上传给服务器，服务器将B的购物篮状态覆盖了原有的状态，购物篮里多了一辆自行车，而A挑选的一本书在B上传后购物篮覆盖过程中被丢失了。这就造成了对用户的操作的不完全服从。这一点也成了REST的缺点。 
总结一下，RPC逻辑复杂，对服务器造成很多的工作量，但分工明确，不容易造成失误。REST逻辑简单，对服务器的工作压力也比较小，但在某些特殊情况下不一定完美的解决问题。