RPC 与 JSON，为啥大家都这么炒作 REST？

Posted 2023-02-16

【中文标题】RPC 与 JSON，为啥大家都这么炒作 REST？

【英文标题】：RPC with JSON, why does everyone hype REST so much?RPC 与 JSON，为什么大家都这么炒作 REST？

【发布时间】：2016-06-03 11:00:32

【问题描述】：

如果我有一个处理 php 应用程序的浏览器、一个 PHP 移动后端和一个用于它们两者的 API，请考虑登录请求。

在 REST 中，所有这些逻辑都必须在浏览器 PHP 应用程序和移动后端的控制器中复制。

不仅会重复，所需的调用量也远远超过 RPC。

REST. 
Call 1 : Fetch user object by email address.
Call 2 : Fetch password by userId.
Call 3 : (If correct password) Change the last login time on user and save user.

这一切都可以通过 RPC 中的一个请求来完成。大量其他示例，其中需要 1 次 RPC 调用但需要 3 次以上的 REST api 调用，更不用说在具有不同身份验证的应用程序之间可怕地重复代码。移动后端使用 OAuth，浏览器使用 PHP 会话。

我不明白为什么每个人都这么大肆宣传 REST，这是我最初被教导编程的方式，但后来我开始了另一份工作，他们使用 RPC 并且效果更好。

我的问题清楚地提出了不同的论点，并展示了不同的建筑形式。不要只是自动标记为重复。

【问题讨论】：

REST vs JSON-RPC?的可能重复

在发布我的问题之前，我已经阅读了该问题，因为 REST 答案在 80 时比 RPC 答案有 120 票。

【参考方案1】：

我会评论而不是回答，但我还没有声誉。

您说的是哪种 RPC？ REST（通过 HTTP）可能更健壮，因为防火墙和网络代理将允许它通过，而使用不同协议和/或非 HTTP 端口的 RPC 可能会被阻止。

听起来严格遵守 REST 原则会使您假设的 REST API 变得比实际需要的更加复杂。您必须保持高度“RESTful”，还是可以将三个操作组合成一个“方法”？或者，您是否可以更改/扩展服务器中的模型以允许一个请求完成所有三个请求，但仍保持 RESTful？例如，PUT 用户的最后一次登录时间，但要求登录凭据伴随请求，如果用户不正确，则请求失败。我承认，这很不直观，但也许你可以想出更好的办法。

我希望您不要以明文形式存储密码，也不要将它们存储为可以将它们转换回明文以进行比较。

【讨论】：

我对密码进行了散列和加盐处理；）

RE：严格遵守 REST 原则，它只能是 REST 动词。基本上 RPC 是由动词组成的。其中，对于非常基于程序的应用程序，我认为 RPC 更好。

【参考方案2】：

正如 Alexandru Marculescu 所指出的，对您的问题的回答隐藏在某个地方 in this flame war。通过“炒作”，我认为您指的是 REST 似乎是连接网络机器的灵丹妙药。我相信这种情绪是 REST 是一种没有标准（甚至不是事实上的标准）的架构风格的结果，因此用户对其应用和解释的方式不同。

表示状态转换 (REST) 的设计确实考虑了 Web 应用程序，因此默认 HTTP 是底层协议。 REST 旨在通过添加 constraints 来实现几个non-functional requirements（例如简单）。

严格遵守 REST 需要遵循 HATEOAS 原则（超媒体作为应用程序状态的引擎），这很少做到。这是允许客户端和服务器解耦的基本约束，因此从长远来看更易于维护（更多关于 Wikipedia）。

这些自我强加的限制的主要缺点是短期效率（正如您所经历的那样）和总体上更高的架构复杂性。

总之，我认为这种炒作源于对真正 RESTful 架构的广泛误解以及 HTTP 端点与 REST API 的区别。

我不想重复您的示例，因为我们可能会在讨论身份验证方案时跑题。我要指出的是，支持多种身份验证方案也不错，而且很容易成为理想的（即社交网络）。