REST是微服务的最佳架构吗？

具象状态转移 （REST） 是 Roy Fielding 博士在 2000 年博士期间提出的一种软件架构风格。

Roy Fielding是HTTP协议的主要设计者，实际上HTTP规范是基于REST架构风格的指导原则设计的。 需要注意的是，REST是一种设计风格，而不是一种标准，如果一个架构符合REST原则，我们称之为RESTful架构。

why？理解 RESTful 架构的最好方法是理解短语 representational state transfer，字面意思是表示层状态转移，省略了主题。 表示层实际上是指资源的表示层，所以通俗地说，就是资源在网络中以某种表示形式转移。

细分：资源：资源，即数据。 例如，新闻源、朋友、订单等;

representational：某种形式的表达，如JSON、XML、JPEG等;

状态转移：状态变化。 由 http 谓词实现。

在Spring这样的框架中，经常有base-back依赖注入、IOC等技术，通过配置文件来确定API调用的覆盖，这不是一个很恰当的比喻，将这些API分开，包装成服务，并将它们放在网络上，每个都有自己的进程，通过与语言无关的协议进行通信，类似于REST， 这变成了一个微架构。

据说好处是易于部署、更灵活、解耦; 缺点是网络限制了性能，不容易确定系统状态等等。

我个人觉得微架构只是把复杂性推到了别的地方，过分强调解耦可能会造成不必要的细化，导致系统更复杂，难以维护，我对这种想法不是很乐观。

REST不仅仅是一种新的架构，它在Web开发过程中带来了一种新的思维方式：通过URL设计系统结构。 在REST中，所有的URL都对应着资源，只要URL设计得好，那么它们呈现的系统结构也很好。

这类似于TDD（测试驱动开发），Tachkela通过测试用例设计系统的接口，每个测试用例代表一组用户需求。 开发者不需要在一开始就写功能，只需要用测试用例的形式表达需要实现的功能。 这类似于REST中通过URL设计系统结构的方式，我们只需要根据需求设计合理的URL，而这些URL不一定非要链接到特定的页面或完成一些行为，只要能直观地表示系统的用户界面即可。

基于这些 URL，我们可以很容易地设计系统结构。 从REST架构的概念来看，凡是可以抽象成资源的东西都可以指定为URL，而开发者的工作就是如何将用户需求抽象成资源，以及如何精确地提取出来。 因为资源的抽象越精确，对REST就越好。

这与传统 MVC 开发模型中基于行动的思维有很大不同。 一个精心设计的 URL 不仅能让开发者更清楚地了解系统结构，还能让用户更容易记忆和识别资源，因为 URL 足够简单和有意义。 按照前面的设计模式，很多URL后面跟着一堆参数，这对用户来说也是非常不方便的。

万维网联盟指出，REST是Web服务构建方式的模型。 REST Web 是 WWW（基于 HTTP）的一个子集，其中 REST Web 提供统一的接口语义，这些语义本质上是创建、检索、更新和删除，而不是任意接口或特定于应用程序的接口，并且仅通过交换表示来操作资源。 所以，现在我们知道了REST是什么，作者将简要列出Roy Fielding在他的**的第5章中提到的所有约束：

客户端-服务器：以这样一种方式实现服务，即用户界面问题（客户端获得可移植性）和数据存储问题（服务器获得可伸缩性）。

解除态势：当客户端和服务器之间实现通信时，服务器在处理请求时从不使用存储在服务器上下文中的任何信息，并且与会话相关的所有信息都存储在客户端中。

缓存：当可以缓存请求的响应（隐式或显式）时，客户端应获取缓存的响应。

统一接口：所有 REST 服务都应依赖于组件之间的相同统一设计。 接口应与提供的 Kaibo 服务解耦。

分层系统：应答客户端永远不知道它们是直接连接到服务器还是连接到某个中间服务器。 例如，可以通过具有负载平衡或共享缓存的功能发出请求。

自治是嘈杂微服务和大服务的设计原则之一，这意味着微服务是全栈服务。 但是，在重构现有的“整体式应用程序”时，SQL 数据库非规范化可能会导致数据重复和不一致。 因此，可以在从整体式应用程序到微服务架构的过渡阶段使用此设计模式

生产者-消费者模型。