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

Question

我正在维护一个充满RPC样式* Web服务的遗留应用程序。例如，我们有以下服务用于从系统创建和删除用户：

• https://example.com/createUser
• https://example.com/deleteUser

客户端通过HTTP POST提交XML数据来调用这些服务。 XML请求包含服务器处理请求所需的所有信息（即，认证信息，用户信息）。然后，服务器使用XML文档进行响应，该文档包含客户端应该知道的任何信息（例如成功/失败标志和描述）。

我对将这些RPC样式服务切换到更RESTful架构的好处感兴趣。根据我的阅读，这意味着以下内容：

1. 要创建用户，仍然需要客户端通过HTTP POST提交XML数据（或PUT，具体取决于他们是否知道最终URL以及他们是否知道用户资源的所有必要信息）。但是，身份验证信息将使用basic authentication在HTTP标头中传递。
2. 要删除用户，客户端会向https://example.com/users/ {用户ID}发出HTTP DELETE调用。同样，身份验证信息将在HTTP标头中传递，而不是在请求正文中传递。事实上，据我所知，不应该有任何请求机构。
3. 服务器应该尝试通过HTTP状态代码/状态描述尽可能多地指示，而不是在XML文档中指示成功/失败信息。

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

1. 我们将利用HTTP提供的更多功能，特别是在身份验证方面。
2. 网址更合乎逻辑，特别是如果我们需要开始在“用户”级别下公开资源（例如https://example.com/users/ {用户ID} / stuff）。
3. 它更符合网络的原生架构。

我错过了什么吗？我觉得使用RESTful架构会有更多好处。

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

Answer 1

Answer 2

嗯......嗯......

REST的主要好处......并不是REST作为架构的直接好处，而是一个伴随的好处 - 是提供更好的资源连接，解锁< / em>来自封闭的通信协议。由于模型的普遍存在，REST接口使连接更容易。

REST“反映了网络的架构”，很不错但没有实际用途。最重要的是走向一个“任何（经过适当授权）可以连接”的世界，或者更相关的是，任何开发人员都知道如何编写连接的程序。

任何开发者，任何系统，任何应用，任何平台，任何设备。看看Facebook应用程序，Twitter应用程序等的丰富内容。让开发人员轻松就是这样。

REST，即架构，不会为您提供连接。 Web协议为您提供连接和集成功能。 REST架构是启用一个可以从任何东西连接的合理系统所必需的。

所以，对我而言，REST就是你所做的，为了通过网络协议向最广泛的受众展示你的好东西。

Answer 3

如果您希望各种可能的客户能够与您的服务进行通信，并且您没有注意到soap-y Web服务客户端几乎普遍存在，您可能会认为REST客户端会给出你有更多的互操作能力。

换句话说，你的忠实记者并没有购买通常支持完整的“Fielding Thesis”超媒体 - 超级算法REST的理论 - 将整个协议表示为一组甚至不均匀的HTTP事务有点像RPC。

然而使用更简单的基于http和json的协议来提供RPC apis，Roy Fielding嘲笑这不是真正的REST，它有一些严肃的优点。一个完整的SOAP-y Web服务堆栈是一件巨大的事情，它带来了大量愚蠢的XML包袱，因为Web服务是根据任意复杂的XML文档而不是逻辑参数集合来定义的。 “Mere-RPC”“休息”服务可以避免这一切。