RPC与REST区别

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

国内对RPC的解释比较齐全也比较权威，但想查些关于REST的就很少了。国内网站对REST的解释实在是很模糊，不知道是我理解的太不彻底，还是写这些文章的本身对概念了解的就不是很彻底，最终我对 REST还是一头雾水。无奈去问老师，结合他的讲解终于对REST有了些实在的理解。后来我感觉，是否是因为这些概念本身是由国外率先提出来的，国内人士对这些概念的理解也无非是通过阅读外文书籍，或是看那些翻译成中文的解释，但在这里我要着重说的是，那些翻译过来的文章的作者是否是在真正理解到了这些概念的精髓之后，才进行翻译同时加入自己对其的理解呢。通过老师的讲解和对国内网站中对REST的认识我发觉，要想真正想理解一些这些概念还得阅读英文原文，

首先，这些概念是作者创造出来的，对概念的理解可谓是最深刻，阐述也可谓最全面；
其次，英文毕竟不是我们的母语，所以从文字结合内容上讲毕竟有一些难度，同一篇文章对中心的理解可能就更相形见拙了，有些甚至只对全文粗率的看了一遍，确已经开始大胆的表述看法，以为也不过如此云云。实际上，对精髓的认识更可能还只是了解到一些皮毛。对这样的学习态度我认为是非常不负责任的，有的已经把自己的看法发布到网上，拜为权威，可谓误人子弟。

我之所以会先到国内网站上搜索是因为，中文毕竟是母语，理解起来可能会快些，也会帮我尽快的入门，预热。可这些曾被我视为权威的文章留给我的只是些片面的皮毛的认识，或者可以说是还不入流。我这样说的本意并不是在讽刺国内相关专业发展程度落后，但学术是不容得一知半解的，是严肃谨慎的。希望那些经常在网上进行专业交流的朋友不要一概的追求长篇大论，以字数和对众多题目的回复量而造成的虚拟声望值来混淆视听，这样只会自欺欺人；而是应该实事求是，对知识的理解到了炉火纯青，相当透彻的地步再进行公开发表。更不要只是看到对问题的解释篇幅很长便视为权威，疯狂转载，经常可以看到网上对某一知识点的解释千篇一律，如果观点是正确的还好，否则就成了有奶便是娘，失之毫厘，谬以千里。总之，对学术要谨慎，要负责任。

言归正传，这里谈谈我结合老师的解释对REST的认识，以及REST和RPC的区别。首先要声明我不敢保证我说的一定权威，可能也很肤浅，但我非常真诚的请求各位如果有感觉我说的不对，或者还不全面的地方给予指出，正确的，我一定会虚心接受。

先来了解一下：
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逻辑简单，对服务器的工作压力也比较小，但在某些特殊情况下不一定完美的解决问题。