BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

云API纷争又起:RPC还是REST

| 作者 Mark Little 关注 12 他的粉丝 ,译者 马国耀 关注 1 他的粉丝 发布于 2011年2月21日. 估计阅读时间: 5 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

InfoQ之前的一篇新闻报道了William Vambenepe的问题“如果云计算的先驱者们都不使用REST,它对于云计算还重要吗?”报道发表之后,William作出了进一步的反馈,试图阐明自己最初那篇博文的中心思想,而这中心思想却被别人忽视了,或者说视而不见。他的本意是:对于开发者而言,抛开语言结构(对象或RPC)底层的交互机制,交互的方法是否通过REST实现并不重要。正如William所言:

方法(Method)调用就是普通的程序员选择怎样编写一段普通的代码。直接在线上调用远程API需要的改变是最少的。RPC的复杂性从来就不是概念上的,而是存在于在实际操作中的。如何序列化方法调用,如何传输?CORBA、RMI、SOAP都曾试图解决这个问题,但是没有一个能完美地保持简单并且能在互联网上足够通用。在此过程中,XML-RPC在一定程度上(不幸地)消亡了。

如他所指出的,AWS使用了一种非常接近XML-RPC的方法。他们在此方法中作出了一些权衡,但是总体来说,AWS采取了实用的方法,最终产生了一种概念上简单却又强大(并且可用)的方法。然而,很多人似乎仍然不同意这个看法,比如Mike Pearce提到:

我知道我是一个REST迷(人们这样称呼那些对REST痴迷的人)。但是事实上,Amazon上并没有证明任何东西,除了傲慢和不尊重开发者之外,什么也没有。

William试图在最近的博文中解释Mike所担心的安歇问题。譬如,其中Mike问到:

AWS使用自己实现的API而不采用标准,比如,哦,我还不知道,REST。对于那些不想学习AWS交互方式却不得不学习的开发者,这难道不是一种折磨么?

Mike对此非常肯定,而William却不这么看……

我很疑惑。我看见过很多开发者艰难地理解REST。我却从未见过哪个开发者被RPC所吓倒。至于REST是一个“标准”的说法,我得去看看规范。不要让我去读博士论文。

William认为,关键的问题不是REST对于云计算的发展是否重要,而是云计算是否已经发展到了那个(开发者或实施者)必须(或应该)作出根本性变革的点。William的观点是,单个提供商产品带来的REST的优势是非常有限的。

云API的使用模式可能会发展到那个点,在这个点上遵循REST规则所能带来的价值是非常诱人的。我只是认为我们还没有到这个点,而且老实说我也不为此激动。在这个热议的问题变成云服务提供商间交互时应考虑的问题之前,云服务还需要许多功能上的改进。而当共享的RESTful API成为最简单的协作API时,共享的RPC API也一定会变得非常容易管理。到那时,最热的话题可能会变成共享语义的问题,而不再是协议了。

还是有一些不同意William的提法的人认为,REST是用在编程接口背后的,在这个层次上谈论它有必要吗?不过,William最初的博文中的一个评论者说:

大多数AWS(或其他云供应商的)用户从来看不到API。他们是通过语言包、或Web客户端应用与这些云服务交互的。所以,真正关心此问题的人是REST迷们,以及库开发者们(比如我)。也许有那种差劲到人们无法使用的API存在,但是AWS Query API远不至于那么糟糕。它相当统一,而且很容易编程。只不过它不是REST。另外,值得一提的是,并非所有AWS服务都是这样的。S3、CloudFront和Route53的API都比较倾向于RESTful。

William最近博文的整体主题是,好的开发者接口可以隐藏非REST API方法,而且还非常有价值,而反过来(译注:REST API却无很好的开发者接口)并不一定是这样的。好接口与底层REST的结合也许是业界最终将会实现的理想世界,但是在现阶段,为了云的成功,既没有必要也没有足够的条件这么做。对于云开发者而言,确保资源语义和编程接口(包括错误处理)的正确性比最好的RESTful接口显得更加重要。

如果你的RPC API足够统一,以至于可使用REST API做其底层模型,那就很好了。

查看英文原文:RPC or REST in the Cloud?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

题目名字写错了 by Qiang Java

RPC写成了PRC

题目名字写错了 by liu shuang

我还纳闷PRC是个什么呢,看了内容才发现题目错了

让我想起某些PHP程序员的论调 by yi yang

如果Discuz都没使用面向对象,那PHP使用面向对象又什么意义?

不知道PRC是啥才进来看的,原来编辑也是标题党。 by lv hongwei

不知道PRC是啥才进来看的,原来编辑也是标题党。

Re: 不知道PRC是啥才进来看的,原来编辑也是标题党。 by 马 国耀

各位读者,对不起!是我的疏忽.谢谢你们指出.望能继续批评指正.

内容 by huang baichuan

内容有点空,有意义的信息不多,不管是使用RPC API或者REST API.是需要根据场景去选择的,选择使用范围,使用对象,性能考虑等等

Re: 内容 by 马 国耀

我也同意您的看法,不同的场景应该有不同的考虑.这篇新闻的确没有提供实施者所需的孰优孰劣,什么情况下使用哪个的深度分析.

然而,新闻的作用是传播业内的各种声音--哪些是当前热议的话题?人们都有什么样的的看法? 其作用是引导我们去进一步探究与思考.我们建议InfoQ的读者们给出自己的看法,参与到讨论中来.碰撞就可能产生火花,形成好的想法.

右侧包含一些深度技术文章,视频采访等内容,建议您关注那些信息.

Re: 内容 by Zou Hao

REST有些时候(在参数比较多的时候)显得非常的不方便,太长的参数字符串导致在DEBUG和测试的时候要多花些时间看看我们是不是把URL抄错了

很是晦涩的语言啊 by 林 石

很是晦涩的语言啊

只是个协议,无必要争论 by Jin Crane

没有万能的协议,无必要争论各自的选择。 没有人会因为AWS不使用REST就放弃使用它的API。 开发者往往把自己的喜好看得过于重要了

看看facebook 的 graph api by sky blue

看看facebook 的 graph api

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

11 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT