我确信标题会引起健康的反应-“嗯，它又开始了……”但是让我在5-10分钟内引起您的注意，我将尽量不欺骗期望。
本文的结构如下：刻板印象的陈述，并揭示了这种刻板印象出现的“性质”。 我希望这可以让您从新的角度来看项目中数据交换范例的选择。
为了弄清楚什么是RPC，我建议考虑JSON-RPC 2.0标准。 REST还不清楚。 而且不应该如此。 您需要了解的所有关于REST的信息与HTTP并没有区别。
RPC请求更快，更高效，因为它们允许批量请求。
关键是，在RPC中，可以在一个请求中调用多个过程。 例如，创建一个用户，向其添加一个头像，并在同一请求中针对某些主题对他进行签名。 只需一个请求，有多少好处！
确实，如果您只有一个后端节点，则使用批处理请求看起来会更快。 因为三个REST请求将需要来自一个节点的三倍的资源来建立连接。
请注意，对于REST，第一个请求应返回后续请求的用户ID。 这也对总体结果产生负面影响。
但是，也许可以在内部解决方案和企业中找到此类基础架构。 作为最后的手段，在小型WEB项目中。 但是，不应像这样构建成熟的WEB解决方案，也称为HighLoad。 他们的基础架构必须满足高可用性和工作量的标准。 情况正在改变。
绿色表示相同情况下的基础架构活动渠道。 注意RPC现在的行为。 从平衡器到后端，该请求仅使用基础结构。 尽管REST在第一个请求中仍然失败，但是弥补了整个基础架构所浪费的时间。
只需在脚本中输入两个请求，而不是五个或十个……并且“谁现在赢了？”这个问题的答案就变得显而易见。
我建议对这个问题进行更广泛的研究。 该图显示了如何使用基础结构通道，但是基础结构不限于通道。 高速缓存是重载基础结构的重要组成部分。 现在让我们获得一些用户工件。 好几次 说32次。
了解RPC上的基础结构是如何“恢复”以满足高负载需求的。 事实是，与RPC不同，REST使用了HTTP协议的全部功能。 在上图中，此功能是通过请求方法GET实现的。
HTTP方法尤其具有缓存策略。 您可以在HTTP文档中了解它们。 对于RPC，将使用不被视为幂等的POST请求，也就是说，重复重复相同的POST请求可以返回不同的结果（例如，在发送每个注释之后，将显示此注释的另一个副本）（ 源 ）。
因此，RPC无法有效地使用基础结构缓存。 这导致您必须“导入”软件缓存。 该图显示了Redis的角色。 反过来，软缓存需要开发人员额外的代码层和体系结构上的重大更改。
现在，让我们计算一下正在考虑的基础架构中有多少请求“诞生”了REST和RPC？
[*]在最佳情况下（如果使用了本地缓存）为1个请求（一个！），在最坏情况下为32个传入请求。
与第一种方案相比，差异是惊人的。 REST的胜利现在显而易见。 但是我建议不要就此停止。 发达的基础设施包括CDN。 通常，他还解决了抵抗DDoS和DoS攻击的问题。 我们得到：
在这里，对于RPC，一切变得非常糟糕。 RPC根本无法委派CDN加载工作。 一个人只能依靠系统来抵抗攻击。
有可能结束吗？ 再说一次。 如上所述，HTTP方法具有其自身的“魔力”。 出于充分的原因，GET方法已在Internet上完全使用。 请注意，此方法能够访问部分内容，能够设置条件以在将控制权转移到您的代码之前解释基础结构元素等。 所有这些使您可以创建灵活，易于管理的基础结构，这些基础结构可以消化很大的请求流。 在RPC中，此方法...被忽略。
那么，为什么神话如此持久以至于批处理请求（RPC）更快呢？ 就我个人而言，在REST能够显示其实力时，大多数项目似乎根本达不到这样的发展水平。 此外，在小型项目中，他更有可能表现出自己的弱点。
REST或RPC的选择不是项目中个人的自愿选择。 该选择应符合项目的要求。 如果项目能够从REST中挤出其真正能够做到的一切，而且确实是必须的，那么REST将是一个绝佳的选择。
但是，如果要获得所有REST利润，您将需要雇用开发人员来快速扩展基础结构，管理员来管理基础结构，架构师来设计WEB服务的所有层...并且该项目每天将出售三包人造黄油...我由于RPC将停止，因为 该协议更加实用。 它不需要深入了解缓存和基础结构的操作，而是将开发人员的重点放在对必要过程的简单且易于理解的调用上。 生意会很高兴的。
RPC请求更可靠，因为它们可以在单个事务中执行批处理请求
RPC的此属性是确定的加号，因为 易于使数据库保持一致状态。 但是使用REST，一切都变得更加复杂。 请求可能会不一致地到达不同的后端节点。
REST的这种“缺点”是上述优势的另一面-有效利用所有基础架构资源的能力。 如果基础架构设计不良，甚至如果项目的架构（尤其是数据库）设计不良，那将是一个很大的痛苦。
但是批处理请求看起来是否可靠？ 让我们看一下这种情况：创建一个用户，用一些描述丰富他的个人资料，并向他发送带有秘密的SMS来完成注册。 即 一批请求中有三个呼叫。
让我们考虑一下该方案。 它为基础架构提供了高可用性元素。 SMS网关有两个独立的通信通道。 但是...我们看到了什么？ 发送SMS时，发生错误503-服务暂时不可用。 因为 发送SMS打包在批处理请求中，然后应回滚整个请求。 DBMS中的操作被取消。 客户端收到错误。
下一次尝试是彩票。 该请求或者再次发送到同一节点并返回错误，或者很幸运，它将被执行。 但是最主要的是，至少在我们的基础架构已经失效之后。 有一个负担，但没有利润。
好吧，让我们想象一下我们拉紧了（！）并考虑了可以部分成功完成请求的选项。 其余的，我们将在一段时间后再次尝试实现（哪个？确定最前面？）。 但是彩票仍然存在。 发送SMS可能性为50/50的请求将再次失败。
同意，在客户端方面，该服务似乎并不像我们想要的那样可靠...但是REST呢？
REST再次使用HTTP magic，但现在使用响应代码。 如果SMS网关上发生503错误，则后端将此错误广播到平衡器。 平衡器收到此错误，并且在不断开与客户端的连接的情况下，将请求发送到成功处理该请求的另一个节点。 即 客户收到了预期的结果，基础架构确认了其“高度可访问性”的高度评价。 用户很高兴。
再说一遍，这还不是全部。 平衡器不仅仅收到响应代码503，建议在应答时为该代码提供“ Retry-After”标头。标头使平衡器清楚地知道，在指定的时间内您不应该在此路由上干扰此节点。随后的SMS发送请求将立即发送到SMS网关没有问题的节点。
如我们所见，JSON-RPC的可靠性被高估了。 确实，组织数据库一致性更容易。 但是，在这种情况下，受害者将是整个系统的可靠性。
该结论与前一个结论大致相似。 如果基础结构简单，那么JSON-RPC的明显优势无疑是它的优点。 如果项目涉及高负载，高可用性，那么REST看起来是一种更准确，更复杂的解决方案。
REST进入阈值低于
我认为上述分析揭露了关于RPC的既定刻板印象，清楚地表明，进入REST的门槛无疑比RPC高。 这是由于需要对HTTP有深入的了解，以及需要对可以在WEB项目中使用的现有基础结构元素有足够的了解。
那么，为什么许多人认为REST会更容易？ 我个人认为，这种明显的简单性来自REST本身。 即 REST不是协议，而是一个概念。REST没有标准，有一些建议。REST并不比HTTP更复杂。 明显的自由和无政府状态吸引了“自由艺术家”。
毫无疑问，REST并不比HTTP复杂。 但是HTTP本身是一个经过精心设计的协议，已经被证明了数十年。 如果对HTTP本身没有深入的了解，则无法判断REST。
但是关于RPC-您可以。 足以满足其规格要求。 那么，您需要一个笨拙的JSON-RPC吗？ 还是狡猾的REST？ 由您决定。
我衷心希望我不要白白浪费你的时间。