39

我正在构建自己的 Ajax 网站，并且正在考虑REST和 RPC。

如果我的服务器支持 Servlet，我只需安装persevere并结束问题，但我的服务器不支持 Servlet。

RPC 更易于编码 (IMO)，并且可以轻松地用 PHP 编写。我只需要一个数据库查询执行器。我正在使用Dojo Toolkit和 JSON。

为什么我应该选择 REST over RPC 或 RPC over REST？

4

3 回答 3

56

理解它的最好方法是阅读 Roy T. Fielding 的论文，或者他博客上的相关文章，他在其中讨论了纯 REST 和简单的 RPC 架构之间的区别。

另一件需要注意的是，关于 REST 的 Wikipedia 文章状况不佳，而 REST 的“发明者”菲尔丁本人则认为该文章不准确。

人们对 REST 最怀念的是可发现性——资源应该在其超文本中包含其他相关资源的 URI，而不是依赖于带外和非标准化的 URI 命名约定。

流行的 RPC 实现（如 SOAP 或 XML-RPC）的一个大问题是它们在自己的专有架构下使用 HTTP，而不是利用 HTTP 的所有不同属性（如 PUT、GET、DELETE 等）。所以这不适合传统的 Web 堆栈也是如此——例如，中间的缓存服务器在不知道 RPC 调用内容的含义的情况下不起作用。

这是对 REST 和 RPC 的不完整介绍，但我想我已经强调了一些经常被忽略的重要点。小心，因为 REST 上有很多错误信息。

也就是说，REST 并不适用于一切。它是一种架构，因此实现它的方式相当灵活。但是，如果主要将事物作为资源访问没有意义，那么 REST 可能不适合，或者它可能只适合您的应用程序的一部分，这很好。

于 2009-07-17T21:08:25.033 回答
29

嗯……说的简单，都是很抽象的模型……太抽象了，自然无处不在……

REST 是使用全局标识符（在 HTTP 的情况下为 URI）以CRUD方式访问的资源的想法（在 HTTP 的情况下使用POST、GET、 PUT 和 DELETE ......好吧，至少那是这个想法）...

RPC 是您在不同的机器上调用过程，传递一些参数并获取返回值的想法......

维基百科上有一个很好的简短比较

Persevere 创建了一个服务，它允许两者（诚然以一种非常优雅的方式）......它是RESTful（尽管它不仅使用 HTTP 功能来实现这一点）并公开一个 RPC 接口......

最后，您应该看看您的应用程序需要做什么......与大多数人一样，您可能最终会得到一个 RPC API（无论是基于XML还是JSON或其他），它包括一个传输层部分 RESTful 子系统...这是因为拥有 RESTfulnes 意味着灵活性...如果客户端可以或多或少地自由遍历服务器上的数据（通过一组简单的 CRUD 方法），它不依赖于有限的（特定问题）通过 API 公开的一组方法，您可以将逻辑转移到客户端......

于 2009-07-08T17:42:25.167 回答
6

提供三种不同风格的服务：

  • RPC API - 客户端向服务发送过程和参数，服务负责执行命令并返回结果。
  • 消息 API（文档 API） ——客户端发送 DOM（元素），它通常是比 RPC API 调用更复杂的结构，因为它们往往不直接暗示操作。
  • 资源 API - 用于访问资源（数据库元组、文件、图像等）。一般来说，它还应该提供良好的媒体类型协商。

SOAP 和 REST 是W3C标准的汇编，主要区别在于 SOAP 使用 HTTP、SMTP 等作为传输协议，而 REST 使用它作为应用程序协议，AKA 它应该支持（GET、PUT、PUSH、DELETE 和 POST ）。SOAP 还意味着使用 XML，而 REST 可以使用任何数据类型（JSON、XML、HTTP 等）。此外，SOAP 的主要优点之一是服务描述符（WSDL 文件），它提供了向客户端自动生成服务连接器（代理）的可能性。

没有灵丹妙药；Web 服务的类型和架构取决于实际的客户端和技术要求。

有关该主题的一般概念，请参阅 Martin Fowler 的签名书籍之一 -服务设计模式

于 2013-01-25T13:00:05.847 回答