REST Web 服务与类似 RPC 的服务有何区别？答案

【问题标题】：What differentiates a REST web service from a RPC-like one?REST Web 服务与类似 RPC 的服务有何区别？
【发布时间】：2011-11-16 15:00:12
【问题描述】：

我有一个使用 AJAX 从服务器获取 JSON 数据的 Web 应用程序。它要求用户首先使用浏览器登录，以便设置 cookie。仅使用 GET 和 POST 动词，其中 GET 用于检索数据，POST 用于修改数据的任何操作。

据我了解，REST 与上述方法的不同之处在于，用户身份验证信息随每个请求一起发送，并且还使用了PUT 和DELETE 动词。

我的问题是，如果端点只是用户的浏览器，那么 REST Web 服务相对于类似 RPC 的方法有什么好处？当客户端未知时，我可以理解 REST 的好处，但是当我只使用 jQuery ajax 调用时，与类似 RPC 的方法相比，这些好处仍然值得吗？

【问题讨论】：

Why would one use REST instead of Web services?的可能重复
不是重复的。另一篇文章更多关于 REST 与 SOAP。 RPC 和 SOAP 不是一回事。它们有时可能相似，但对于简单的事情，RPC 可能比 SOAP简单得多。

标签： jquery ajax json rest rpc

【解决方案1】：

REST 和 RPC 最大的区别之一是 REST 是关于资源的，而 RPC 更多的是关于动作的。例如，对于真正的 RESTful 服务，您永远不会调用像 http://domain.com/service/User/jason/add 或 http://domain.com/service/User/addUser?username=jason 这样的东西。使用 RESTful 服务，您只需引用 URL 中的资源，然后使用 HTTP 动词和请求正文定义如何处理该资源。因此，对 http:/domain.com/service/jason 的 GET 请求应返回有关资源（jason 用户）的信息。你可以更具体地说http://domain.com/service/user/jason，但结果应该是一样的。如果您要添加一个名为 jason 的用户，您将使用完全相同的 URL http://domain.com/service/user/jason，但您将使用 PUT 动词，并且请求的正文将包含其他数据。要删除 jason 资源，您将再次使用完全相同的 URL (http://domain.com/service/user/jason) 并使用 DELETE 动词。要更新，您将使用 POST 动词。

REST 非常适合您打算供其他开发人员使用的面向公众的 API。它们可以做得非常标准，这样它们就不需要大量关于使用服务的现有知识。没有 WSDL 调用等。由于无状态，它还可以使它们在部分网络故障期间更加稳定。

根据您的描述，我认为您不需要真正的 RESTful 服务。但是你可能需要考虑，如果你需要一个更标准的 API。我为一个仅用于内部使用的项目创建了一个 REST 服务，但那是因为我打算从潜在的数十个其他服务以及将来可能从其他开发人员那里访问该服务。所以即使一开始我只是在几个项目中使用它，最终目标还是需要一个更标准的界面。

【讨论】：

由于 REST 在资源而不是操作的概念上运行，您将如何处理诸如“用户单击“隐藏侧边栏”链接，Web 应用程序应修改后端的首选项，以便从那时起它就被隐藏了”？
我可以看到使用 REST 进行类似操作的唯一方式是，如果您存储浏览网站的用户的客户端表示并显示侧边栏是该用户的首选项设置。当他单击“隐藏侧边栏”时，您将为该用户设置该首选项并发送 POST 请求以使用新首选项更新该用户。但我认为这将是一个奇怪的用例。我认为大多数开发人员根本不会尝试使用 REST。
@Daniel GET /mysite/mypage?withSidebar=true 是一种方法。
假设您在后端有一个 /users/user_name（或只是 /user_name）“资源”，我将使用 PUT 到 /users/user_name/preferences 来处理这个问题。当您的应用程序启动时，它会通过 GET 访问 /users/user_name/preferences 以了解如何配置自己。
> 如果要添加用户...您将使用PUT 动词...要更新您将使用POST 动词。

【解决方案2】：

这样想——重要的是功能，还是正在采取行动的信息？

当您处理 REST 时，您正在处理一种信息状态 - 您查看当前信息是什么 (GET)，或者更改特定文档（POST、DELETE），或者创建一个新文档 (PUT)。

对于 RPC，它是关于过程/函数/方法/操作...无论您用您的语言如何称呼它们。信息只是被操作或从服务返回的东西……但它可能是众多信息之一。我们可能正在搜索并返回一个项目列表。或者我们可能正在协商一些需要来回交互的事情。（REST 的协商大部分是通过 HTTP 来处理的，所以你必须用 Accept 和 Accept-Language 头来做事情）但是更重要的是操作。

然后是第三种类型，即文档/文字 SOAP ... 其中重要的是消息，您必须根据消息猜测被调用的函数是什么。如果您只是处理 CRUD 操作，这可能没问题。在这种情况下，与 REST 相比的优势在于您仍然可以拥有 WSDL，因此您可以提前知道要发送哪些必要元素，以及期望得到什么回报。

它们都有效...主要是关于您如何看待问题，以及从您已经必须将其公开为 API 的转换是多么容易。如果你是从头开始，你可以做任何你想做的事。我个人喜欢 SOAP（document/lit 或 RPC），因为我可以提供一个 WSDL 文件，有人可以使用它来引导他们的客户端。我遇到过人们在几个小时内进行严肃查询的案例。（解释 API 的一些抽象细节，例如发送空字符串与发送 null 之间的区别需要一些时间，但我会遇到与 REST 相同的问题）

【讨论】：

>> 或者您更改该特定文档（POST、DELETE），或者您创建一个新文档（PUT）POST 用于创建新资源，PUT 用于创建或更新。

【解决方案3】：

最好将 REST 描述为与资源一起使用，而 RPC 更多的是关于操作。

休息： 代表代表性状态转移。这是一种组织独立系统之间交互的简单方法。 RESTful 应用程序使用 HTTP 请求来发布数据（创建和/或更新）、读取数据（例如，进行查询）和删除数据。因此，REST 将 HTTP 用于所有四个 CRUD（创建/读取/更新/删除）操作。

RPC： RPC 基本上用于跨不同模块进行通信以服务用户请求。例如在 openstack 中，例如 nova、glance 和 neutron 在启动虚拟机时如何协同工作。

REST/RPC：

作为一种编程方法，REST 是 Web 服务和 RPC 的轻量级替代方案。与 Web 服务非常相似，REST 服务是：

独立于平台（不管服务器是 Unix、客户端是 Mac 还是其他），
语言无关（C# 可以与 Java 等对话），
基于标准（在 HTTP 之上运行），并且
可以在有防火墙的情况下轻松使用。

【讨论】：

【解决方案4】：

关于 REST 与调用对象的耦合较少，您是正确的 - 如果您与需要从服务器调用 WSDL 文件的 SOAP Web 服务进行比较，那么，REST Web 服务的耦合较少（即不需要在调用 Web 服务之前了解它）。大多数情况下，令牌需要与给定“表示”的请求一起传递。

我不认为从 ajax 使用 REST 有很大的好处，事实上，根据您正在处理的 API，您可能需要一个令牌，该令牌作为 URI 参数（查询字符串参数）在使用基于 SOAP 的 Web 服务，这不是必需的。将 SOAP Web 服务与 ajax 调用结合起来，以 JSON 格式传递数据并将 JSON 反序列化为服务器端的对象实际上非常容易。最重要的是，jQuery 让这一切变得超级简单。

【讨论】：

这只是理论上调用者需要较少知识的情况。对于大型服务，您必须知道的数量是等效的（因为 either SOAP 或 REST 没有描述困难的部分，尽管具有适当语义扩展的 WSDL 可能是最好的 - 不是任何人都为那些东西烦恼）。

【解决方案5】：

讨厌把它打破给你们所有人。 RPC 进行本地调用，抽象底层远程行为。你猜怎么着？做 REST 是一回事。关于 REST 是关于资源的论点是不正确的，你实际上直接调用动作。

我声称带有 json 的 REST over HTTP 是 RPC 的一种形式。

其他流行的 RPC 可能包括例如 SOAP

【讨论】：

这是最简单的解释。

【解决方案6】：

RPC 和 REST 只是不同的方法，各有利弊，两者都取决于上下文。您甚至可以在一个 API 中混合使用这两种方法。

上下文，这是关键。没有灵丹妙药，不要盲目追赶时尚，总要在一个情境中思考，选择解决方案一定要务实。

了解更多here!.

【讨论】：