使用JSON的RPC，为什么每个人都如此炒作REST？

Question

如果我有浏览器处理PHP应用程序，PHP中的移动后端以及其中2个的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并且工作得更好。

我的问题清楚地提出了不同的论点，并展示了一种不同的架构形式。不要自动标记为重复。

Answer 1

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

你在谈论什么样的RPC？ REST（通过HTTP）可能更强大，因为防火墙和Web代理将允许它通过，而使用不同协议和/或非HTTP端口的RPC可能会被阻止。

严格遵守REST原则听起来让您假设的REST API比它需要的更复杂。您是否必须保持高度＆＃34; RESTful＆＃34;，或者您可以将这三种操作合并为一种＆＃34;方法＆＃34;？或者，您是否可以更改/扩展服务器中的模型以允许一个请求完成所有三个但仍保持RESTful？例如，PUT是用户的上次登录时间，但要求登录凭据随请求一起提供，如果请求对用户不正确，则请求失败。我承认，这是不直观的，但也许你可以想到更好的东西。

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