简单来说啥是 REST、RESTFul、SOA 和微服务？

Posted 2023-02-25

技术标签:

【中文标题】简单来说啥是 REST、RESTFul、SOA 和微服务？【英文标题】：what are REST,RESTFul, SOA and microservices in simple terms?简单来说什么是 REST、RESTFul、SOA 和微服务？ 【发布时间】：2015-01-19 04:10:34 【问题描述】：

我以为我知道 REST/“RESTFul”、restfulservices、webservices、SOA 和微服务是什么，但我遇到了太多不同的定义，以至于我得出的结论是这些术语被过度使用、误用或只是定义不当。

我希望对上述术语的含义，具体定义，共性和差异，优缺点，以及最重要的底线有一个清晰的了解 - 为了正确使用这些术语，最重要的事情要记住.

【问题讨论】：

浏览 mkyong 教程 “微服务就是 SOA，对于那些知道 SOA 是什么的人来说”（c） REST 肯定被过度使用了。 【参考方案1】：

_{免责声明：这篇文章的大部分内容都是主观的。这里没有试图严格定义任何东西，只是试图将概念置于上下文中并给出概念的全局概述以及它们之间的关系。}

我以为我知道 REST/“RESTFul”、restfulservices、webservices、 SOA 和微服务

我想说所有这些术语都属于面向服务的架构 (SOA)。 Web 服务是使用 Web 相关技术的 SOA。 REST 及其子集 RESTful 是一组实现 Web 服务的实践。最后，微服务是一套新的 SOA 实践。

我希望对上述术语有一个清晰的了解代表

我将尝试解决这一点，但使用非正式的定义，而不涉及优点和缺点。那太长了，我认为最重要的观点应该从解释中显而易见。

SOA

我认为在这种情况下这个名称是不言自明的：SOA——代表面向服务的架构——指的是以服务为中心而设计的架构。现在，这里的棘手部分是您可能会或可能不会考虑服务，这是一个完全不同的主题。

网络服务

这说明了使用 Web 相关技术的 SOA 子集。这通常涉及 HTTP 和 XML，但也可以使用 FTP。我认为这里的术语 web 非常模糊，因为它通常指的是标准的 Internet 技术。

REST(ful)

REST 是 Web 服务的一个子集——因此是 SOA——它围绕着使用 HTTP 进行通信。有一组特定的常见做法，例如与 URL 的特定相关性。

大约 10 年前，当我被介绍给 REST 时，RESTful 被作为一种更严格的 REST 实现呈现给我，其中资源将具有唯一的 URI，并且将通过映射到 HTTP 动词的 CRUD 操作进行管理 -- 创建 = POST，读取 = GET，更新 = PUT，删除 = 删除。

通过 HTTP GET 或 POST 请求或/users/1/update URL 更新用户信息在 REST 中完全有效，但它不是 RESTful。对于后者，方法是使用 HTTP PUT or PATCH 而不是 /users/1（这也是其余操作的 URL，只是改变 HTTP 动词）。

我发现这种区别多年来变得模糊。然而，RESTful 仍然是 REST 的一个更严格的子集。（具体要求可能有争议。）

_{编辑 - 更正式的定义：}

_{REST 代表 Representational State Transfer 并且是 presented by Roy Fielding in his Ph.D. thesis 作为分布式超媒体系统的架构风格。重点进入超媒体和自我控制，使客户与大多数事先了解的知识脱钩。一个网站就是一个例子：它由一个单一的 URI（网站根）和一个媒体类型 (html) 组成，服务器通过它提供客户端所需的有关资源和所有可能交互的所有信息。}

_{我想说 99% 的人谈论 REST 的真正意思是 RPC or HTTP-based interfaces：使用 HTTP 端点来调用某些操作或查询数据。亲自上阵has tried to clarify this。由一组预定义的 URL 组成的任何 API 都需要某些 HTTP 动词和一些参数，都属于这 99%。我上面的描述也是如此。然而，我怀疑这个词本身能否在它的误用中幸存下来，我认为我们必须接受它的新含义。}

微服务

这是最近的术语；它提倡将应用程序实现为一组简单的可独立部署的服务。这与 SOA 架构的经典方法形成鲜明对比，SOA 架构是一组用于构建复杂系统的非常复杂的服务，通常涉及企业服务总线。然而，需要注意的是，虽然 SOA 通常与此类系统相关联，但它是一个更广泛的术语，实际上，微服务也是 SOA 的一个子集。

微服务通常与现代 javascript 全栈一起出现——即，从服务器到用户界面的所有垂直组件都使用 JavaScript。可以说之所以如此，是因为使用这些 JavaScript 的全栈可以加快开发速度，这要归功于简化的集成。这些堆栈以及因此使用它们实现的微服务通常是通过 REST 构建的，但从理论的角度来看，没有什么能阻止您使用不同的方法来实现相同的理念。

【讨论】：

REST 约束在这里定义：ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm（应用 HTTP 标准只是其中的一小部分）大多数人从未阅读过它们的问题，即使他们声称他们知道 REST 是什么。 RESTful 只是一个术语，因为 REST 被过度使用。 API 是一个术语，因为 RESTful 被过度使用。我们已经说不出话来了…… 可悲的是，这些术语与业内许多其他术语一样被过度使用（通常是由于围绕它们的炒作），以至于它们的定义变得模糊，我们必须不断更新我们对它的看法。 RESTful 概念从我所学到现在的演变只是又一个例子。 @jnovo “通常涉及企业服务总线” - 在微服务的上下文中，ESB 的替代方案是什么？只是让微服务直接相互通信？如果我正确理解 ESB 是什么（来自 Wikipedia 和其他 SO 线程），它只是一个中间件路由器，服务通过其抽象以不可知的方式相互交谈。 @jnovo ` Create = PUT，Read = GET，Update = POST，Delete = Delete。` 不是在这里交换了 put 和 post 吗？【参考方案2】：

让我向您介绍这些术语的分类学观点：