VS-RPC 对比 REST

互联网上充斥着文章,博客文章以及关于RPC和REST的讨论。 大部分目标都是回答有关使用RPC或REST作为特定应用程序的问题,这本身就是一种错误的二分法。 提供的答案通常会给我留下一些希望,并给我的印象是有大量开发人员插入RESTful体系结构,因为他们被告知REST很酷,但不知道为什么。 具有讽刺意味的是,Roy Fielding在他引入和定义REST的论文中对这种“时尚设计”类型提出了质疑:

“考虑我们看到软件项目多久会在采用最新时尚体系结构设计的时候开始,而后来才发现系统需求是否需要这样的体系结构。”

如果您想深入了解REST并且只能读取一个文档,请不要阅读本文。 在这里停下来阅读菲尔丁的论文 。 如果您没有时间阅读他的论文,或者您只是在寻找关于RPC和REST的高级概述,请继续阅读。 首先,让我们仔细看一下RPC,REST和HTTP。

远程过程调用 (RPC)是描述一种机制的方式,它允许您在另一个进程中调用过程并通过消息传递交换数据。 它通常涉及在客户端进程上生成一些方法存根,这使得调用看起来是本地的,但在存根后面是逻辑来整理请求并将其发送到服务器进程。 服务器进程然后解组请求并调用所需的方法,然后重复该过程,以获取该方法返回给客户端的任何内容。 HTTP有时被用作消息传递的底层协议,但没有任何关于RPC的内容被固定地绑定到HTTP。 远程方法调用(RMI)与RPC密切相关,但通过使远程调用面向对象并提供保持对远程对象的引用并调用其方法的功能,远程调用又迈进了一步。

具象状态传输 ( Representational State Transfer ,REST)是一种架构风格,它在接口上强加一组特定的约束来实现一组目标。 REST强制执行客户机/服务器模型,客户机有兴趣获取信息并对由服务器管理的一组资源进行操作。 服务器通过一次提供一个或多个资源的表示并提供可以获取资源的新表示或操作资源的操作来告诉客户端资源。 客户端和服务器之间的所有通信都必须是无状态和可缓存的。 据称REST体系结构的实现是RESTful。

超文本传输​​协议 (HTTP)是用于在分布式系统中公开资源的RESTful协议。 在HTTP中,服务器通过在HTTP请求的主体中提供有关这些资源的表示来向客户端通知资源。 如果主体是HTML,则在A标签中给出合法的后续操作,这些操作可以让客户端通过额外的GET请求获取新的表示,或者通过POST / PUT或DELETE请求对资源进行操作。

鉴于这些定义,有几个重要的观察要做:

  • 谈论RPC vs REST是没有意义的 。 事实上,通过创建符合REST约束的方法,您可以在任何RPC实现之上实现RESTful服务。 您甚至可以在RPC实现上创建一个HTTP样式的REST实现,方法是创建GET,POST,PUT和DELETE方法,这些方法接受一些反映HTTP头的元数据并返回一个镜像HTTP请求主体的字符串。
  • HTTP不会将1:1映射到REST,它是REST的一个实现 。 REST是一组约束,但不包括HTTP特定实现的各个方面。 例如,您的服务可以实现一个RESTful接口,该接口公开的方法不是HTTP公开的方法,而仍然是RESTful方法。

当他们询问他们是否应该使用RPC或REST时,真正问的是: “我应该通过通过vanilla HTTP公开我的资源来使我的服务成为RESTful,还是应该建立在像SOAP或XML-RPC这样的更高级别的抽象上以公开资源以更定制的方式?“ 。 为了回答这个问题,我们先来探讨一下REST和HTTP的一些好处。 请注意,虽然所有参数适用于后者(但反之亦然),但为什么您希望制作RESTful服务以及您为什么要使用vanilla HTTP,有单独的参数。

REST的优点在于,来自任何州的合法行为总是由服务器控制。 与客户的合同非常少, 在HTTP的REST实现中,合同是一个可以发送GET请求的顶级URI。 从这一点开始,服务器在运行时将一组法律行为交给客户端。 这与典型的RPC实施形成了直接的对比,其中一系列法律行为更加僵化; 如由客户使用并在构建时显式调用的过程所定义的。 为了说明这一点,考虑通过导航到网页找到特定产品和遵循一系列链接(例如产品类别等)之间的区别,直到找到所需内容为止,然后调用过程按名称获得产品。 在第一种情况下,只能在服务器上对API进行更改,但在第二种情况下,需要对客户端和服务器进行协调部署。 这个例子的一个显而易见的问题是,计算机并不擅长以动态的方式使用API​​,所以如果你正在构建一个服务来使用服务器,很难(但在大多数情况下)可以获得服务器控制的操作的好处由其他服务。

使用vanilla HTTP来公开资源的一个主要优点是您可以利用为HTTP构建的大量技术,而无需额外的工作。 考虑一个具体的例子,让我们看看缓存。 由于HTTP响应的输入已被很好地定义(查询字符串,HTTP标头,POST数据),我可以在我的服务之前站起来一个Squid服务器,它可以开箱即用。 在RPC中,即使我使用HTTP进行消息传递,也不能保证消息与过程调用映射1:1,因为单个调用可能会根据实现传递多个消息。 此外,RPC过程的输入可能会或可能不会以标准方式传递,从而可能将请求映射到缓存的响应,并且请求可能包含或不包含适当的元数据以知道如何处理缓存(如HTTP) 。 不必重新发明轮子,高速缓存只是HTTP使我们有能力站在他人肩膀上的一个例子。

HTTP的另一个优点是我会简单介绍一下,它通过GET,POST / PUT和DELETE操作以非常通用的方式公开资源,这些操作经历了时间的考验。 在实践中,当你以自己的方式公开资源时,你可能会以对于将来的用例过于狭窄的方式公开事物,这会导致方法,接口或服务数量的爆炸,最终变成你的SOA的一部分。 这一点真的需要一个自己的博客文章,所以我会避免在这个特定的职位更深入。

VS-RPC 对比 REST》有1个想法

评论已关闭。