【问题标题】：REST vs RESTful Web ServiceREST 与 RESTful Web 服务
【发布时间】：2017-01-27 15:03:45
【问题描述】：

SOA 架构风格基于企业业务架构并介绍了两个高层抽象：企业业务服务和业务流程... 另一方面，REST 是一组表达的架构指南作为面向资源的架构（ROA）。 ROA基于资源的概念； ... 不可能使用真正的 REST 构建 SOA 系统。

和

REST Web 服务方法是一种纯粹将 REST 用作一种构建 SOA 的通信技术。在这种情况下，服务是使用 SOA 样式分解和基于 REST 的 Web 服务定义被用作运输工具。

您能否更详细地解释最后的报价？他们的意思是 RESTful Web 服务与 REST 有什么不同，或者不仅仅是 REST 还是什么？他们将 REST 用作通信技术是什么意思？他们所说的“基于 REST 的 Web 服务被用作传输”是什么意思？

更新：为 tonicsoft 回答

由于您无法使用纯 REST 构建 SOA（就像带有纯名词的句子）我想知道在适合 REST 的地方安排应用程序部分的正确方法是什么？不是吗？我应该将 REST 部分与非 REST 部分分开吗？非 REST 部分应如何相互通信以及与 REST 部分通信？

【问题讨论】：

对于 SO 来说似乎不是一个好问题，而是另一个 stackexchange 站点
@GillesQuenot 建议我在另一个网站上找到这个问题的答案。
@GillesQuenot 这个问题不适合程序员 - 它会很快被否决并在那里关闭，请参阅Discuss this ${blog}。推荐阅读：What goes on Programmers.SE? A guide for Stack Overflow
@GillesQuenot 我注意到您在程序员中的声誉为零，并且从未发布过（或您的帖子已被删除）。请不要建议cross-posting，尤其是当它涉及到您不参与的社区时。
大家好，我只知道 SO 是针对编码问题（你知道，现实生活中的代码问题），我猜这不是其中之一。

标签： web-services rest architecture soa

【解决方案1】：

是的，这篇文章说 REST 不同于“RESTful Web 服务”。

作者将 REST 比作“名词”而不是动词，或网络的“DBMS”。我可以不使用动词写一个句子吗？不可以。我可以仅使用 DBMS 构建系统吗？不可以。同样，不能仅使用 REST 架构原则来构建系统。在大多数系统中，REST 语义最终会崩溃。本文中给出的一个示例是需要消息传递解决方案时。

我认为作者说“RESTful Web 服务”是整个句子，而 REST 只是名词。在“RESTful Web 服务”中，系统中没有 REST 语义的部分（基本上任何不是 CRUD 的）都可以使用在纯 REST 组件的实现中常见的类似技术和编程风格来实现。

“REST 作为一种通信技术”基本上只是意味着将服务的传输实现限制为 HTTP。大多数 Web 服务框架为传输提供了多个选项（例如，WCF 可以通过 HTTP 执行 SOAP，或使用共享内存，或 TCP 用于没有 HTTP 的网络服务）。 REST 回避了这种灵活性，倾向于简单。根据我对引用文章的解释，“RESTful Web 服务”将完全基于 HTTP。

总之，REST 只是一种架构风格。仅使用一种架构风格来构建任何值得注意的技术解决方案是不可能的。因此，“RESTful Web 服务”是一种在适当情况下利用 REST 架构原则的简单 Web 服务。

同样，这不是我的观点，这只是我对文章内容的解释。

如何将纯 REST 操作与“RESTful Web 服务”的其余部分分开

我认为在纯“REST”端点 (CRUD) 和更多面向行为/服务的端点之间不需要任何特定的分隔，除了任何给定的 URL 应该是一个或另一个这一事实之外，您可以发现你不想在同一个基本 URL 下混合两种样式。例如，如果您有一个 REST 端点来检索 id=1234 的用户帐户的详细信息：

/users/id/1234

并且您想要实现“验证电子邮件”工作流程（为了论证的缘故，它没有作为 REST 服务实现），然后为您的验证电子邮件工作流程/服务选择一个不与 REST 样式 /users 冲突的 URL /API。不要试图做这样的事情：

/users/id/1234/verifyEmail?securityToken=XXXX

但是，更愿意为此端点创建一个全新的 URL：

/verifyEmail/userId/1234?securityToken=XXX

这些指导原则在很大程度上是任意的：重要的是以一种对其他程序员有意义的方式设计您的服务，因为这些人将使用您的服务。与任何其他软件设计一样，Single Responsibility Principal 将使您走得更远。每个基本 URL 应该只做一件事！

【讨论】：

感谢您回答这个问题！抱歉，但我仍然需要 somrone 为非 REST 部分带来光明。我更新了我的问题，你能看看吗？
答案已更新——我认为这并不重要，只要您的应用程序被很好地组织成不同的 URL。在同一个应用程序中拥有纯 REST 和非纯 REST 端点是完全可以的。

【解决方案2】：

正如引言中提到的，H 超级媒体作为 E 应用程序状态 (HATEOAS) 约束的引擎是其中之一最不了解的约束，因此很少实施正确。对许多服务声称的事实感到恼火无论违反超媒体，都要保持 RESTful 约束，菲尔丁 [29] 非常清楚地表明，超媒体是一个基本要求，但由于 REST 一词是如此广泛误用，社区努力寻找替代术语，例如 Hypermedia API ，真正表示 RESTful 服务

REST 架构具有明确定义的约束，您可以在此处找到：http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

据我所知，RESTful 一词来自 Richardson 成熟度模型。 http://martinfowler.com/articles/richardsonMaturityModel.html我不知道原始文章在哪里，但据我所知，这是一些废话，比如你应该调用每个 API REST，它至少满足一个约束，你应该只调用 RESTful 那些 API满足每个 REST 约束。 Fielding 多次明确表示，只有满足所有约束的 API 才被视为 REST，而那些不是简单 Web API 的 API 则不是 REST API。遗憾的是，对 REST 一无所知的开发人员过度使用 REST 和 RESTful 词。他们中的大多数人甚至不知道存在 REST 约束。对他们来说，REST 只是 CRUD 和 URI 设计。只需检查有关 REST 的 SO 问题，99% 就是这样的东西。更有趣的是，当我回答与 REST 相关的问题时，我从他们那里得到了减分……所以为了避免混淆和误解，我们现在构建了超媒体 API，所以只要人们不开始使用这个词，我们就可以一起生活...

我无法理解大多数问题。我在这里和很多人一起比较了 REST 和 SOAP Representational state transfer (REST) and Simple Object Access Protocol (SOAP)也许你找到了你问题的答案。

非 REST 部分应如何相互通信并与 REST 通信零件？

如果您指的是应用程序部分的microservices，那么 ofc。 SOA 和 REST 微服务可以通过相互发送 HTTP 和 SOAP 消息来相互通信。如果您没有旧的 SOAP 系统，那么我建议您只开发 REST 服务，因为 SOAP 是有状态的，因此它的扩展性不如 REST。

【讨论】：