web-services - 将旧式RPC样式服务切换到REST有什么好处？

Question

我正在维护一个充满RPC样式* Web服务的旧版应用程序。例如，我们提供以下服务来从系统创建和删除用户:

https://example.com/createUser

https://example.com/deleteUser

客户端通过在HTTP POST上提交XML数据来调用这些服务。 XML请求包含服务器处理请求所需的所有信息(即身份验证信息，用户信息)。然后，服务器以XML文档进行响应，该XML文档包含客户端应了解的任何信息(例如，成功/失败标志和说明)。

我对将这些RPC样式的服务切换到更RESTful的体系结构有什么好处感兴趣。根据我的阅读，这意味着以下内容:

要创建用户，仍然需要客户端通过HTTP POST(或PUT，取决于他们是否知道最终URL以及是否知道用户资源的所有必要信息)提交XML数据。但是，身份验证信息将使用basic authentication在HTTP header 中传递。

要删除用户，客户端将向https://example.com/users/ {user id}发出HTTP DELETE调用。同样，身份验证信息将在HTTP header 中传递，而不是在请求正文中传递。实际上，据我所知，不需要任何请求主体。

服务器应该在HTTP状态代码/状态描述中尽可能多地指示，而不是在XML文档中指示成功/失败信息。

现在，据我所知，将这些服务更改为更RESTful架构的主要好处是:

我们将利用HTTP提供的更多功能，特别是在身份验证方面。

这些URL更具逻辑性，特别是在我们需要开始在“用户”级别以下公开资源的情况下(例如https://example.com/users/ {user id}/stuff)。

它更符合Web的 native 体系结构。

我有什么想念的吗？我觉得使用RESTful架构应该有更多的好处。

*请注意，当我说“RPC样式”时，我并不是指XML-RPC或SOAP之类的标准化格式。

Answer 1

从实用和务实的角度来看，如果不了解您的应用程序，那么转换为REST并不会带来任何好处，尤其是考虑到潜在的开发工作。

您有庞大的客户群吗？你有很多服务器吗？

REST的一个关键属性(但不是唯一的，甚至不是必需的，而是...)是它如何利用HTTP缓存。

您正在缓存吗？这对您来说很重要吗？它适用于公共(public)互联网上的大型系统。

如果您不使用缓存，并且您认为它不会给您带来很多好处(即您没有很多客户端，您的服务器并没有变得非常饱和，您的内容就无法很好地容纳等等)。 )，那么REST甚至不值得追求，因为其他好处远没有缓存明显。

如果您只是通过HTTP发布POX(普通Ol XML)(或JSON)，并且对您来说效果很好，那么我就不用担心。

当然，HTTP还有其他好处，包括媒体类型，内容协商，缓存和位置 header 等。但是，认真的说，如果您不希望对API进行太多操作，那就不要打扰。

如果缓存将为您提供帮助，那么值得更全面地使用HTTP协议(protocol)和堆栈，但是没有理由为此使用REST体系结构。通过HTTP缓存的POX也不是REST。它...通过HTTP的POX。

这就是所有的SOAP和XML-RPC ... HTTP上的POX，只是SOAP XML带来了几个非常严格的标准...

如果您是一个庞大的服务机构，并且有10年的计划，那么您可能希望考虑迁移到完整的REST架构，因为这在世界范围内是一个真实的地方-长期的大型系统。

但这确实是重新设计的方法。

附加物:

REST试图解决的问题之一是系统的耦合。

RPC系统往往紧密耦合。

因此，随着系统的发展，这种耦合成为拖延系统发展的障碍。

考虑一下MS Windows和Linux的两个极端。微软花费大量时间试图使MS Windows向后兼容以与旧版(甚至是错误的)软件一起使用。那花费他们时间和金钱。

相比之下，Linux内核则更为轻巧。当涉及到内核时，它们对向后兼容性没有任何保证。 Linux以其破坏驱动程序而闻名，因为它在发行版与发行版之间不兼容。他们主要的节省之处是，他们一开始就没有 promise 任何事情，所以当事情破裂时不要感到沮丧。

这使Linux内核专家更具创造力，并且移动速度更快，因为他们可以随时随地扔东西并更改事物。这也使团队更小。

现在考虑一个小型的RPC服务系统。由于它们隐式地紧密地绑定(bind)在一起(就像RPC的本质一样)，所以当中央服务发生更改时，该更改将波及到所有客户端。

如果这些客户很少，尤其是在您的控制之下(当您开发整个系统而不是组件时)，那么变化的幅度并不一定是痛苦和破坏性的。

但是您可以看到，如果您有成千上万的客户和/或不受规范控制的客户，对核心服务进行更改可能会产生巨大的影响。哎呀，我给人们发送了源代码，但他们仍然弄错了。

REST通过利用标准媒体类型(即您一天不会在白板上扔出的XML)，HTTP协议(protocol)(不需要HTTP来拥有REST拱门，但今天已经足够了)和HATEOS来帮助分离系统。

大致来说，HATEOS是客户端不对事物前进的方向进行任何假设的地方。客户端将解析结果以获取指向其执行过程中的后续步骤的链接。

经典示例是您(客户)在亚马逊购物。您所知道的只是单击“ checkout ”按钮，但是您不知道要转到哪个URL。该URL可以一成不变，可以每秒更改，甚至可以导致重定向。你不知道，也不在乎。这是服务器的特权。

因此，作为客户端，您知道如何“单击 checkout ”(即，按照最新有效负载中标有“ checkout ”的链接)，但您实际上不知道更多。值得注意的是，您的应用程序中没有硬编码的“http://amazon.com/checkout”。

无需详细介绍如何使用这些概念来减少耦合，现阶段只需接受它们即可，并且通过减少耦合，您可以作为服务提供者拥有更轻松的机制来扩展，添加和更改服务，而作为服务使用者，您可以可以使您的系统专注于您特别感兴趣的服务方面，即使某些基本细节在背后有所变化。再次考虑一下亚马逊多年来发生的变化，但至少我们都知道Checkout按钮在哪里。

但是，编写这样的服务并创建这样的客户确实需要很多工作。有些机制是“简单的”，因为“我们一直都在做”(例如，提供HTML响应，谁不这样做？)。但是，与媒体类型打交道的范围更广，可以促进变更和发展，并使您的服务和客户对这种环境更加健壮和友好。一切都需要付出努力，而 yield 却没有立即实现。

“为什么我们要为一项永远不变的服务而做所有这些事情？”

“因为永远不会比您想象的要早。”

Web应用程序(如Amazon)以RESTy方式获得成功，因为它们的客户恰好是人类，这使得(大多数)适应性很强。但是，如果您曾经在热门网站上移动过某些核心功能的按钮，则收件箱会让您知道某些人的适应能力。在机器级别执行此操作甚至更加困难。

介意，这与“敏捷，我们可以稍后再添加”的思维方式形成鲜明对比。

这就是为什么REST更适合于具有长期前景的大型系统。它比战术更具战略意义。它不仅仅是将位插入套接字以获得结果。

希望能有所帮助。