REST状态

REST中的S代表状态。 不幸的是，国家是一个重载的词。

在本文中，我将讨论适用于REST API的两种不同类型的状态。

应用领域

第一种状态类型是应用程序状态 ，例如在Hypermedia As the Application of Engine State （HATEOAS）中， 这是REST体系结构风格的显着特征。

我们必须首先了解RESTful架构中的应用程序究竟是什么，不是。 一个REST API是不是一个应用程序的接口，但是对于一个应用程序的接口。

RESTful服务只是一堆相互关联和互连的资源。 它们本身并不构成应用程序。 这是将这些资源变成应用程序的一种特殊的使用模式 。

术语“应用程序”与客户端的关系比与服务器的关系更大。 可以在相同的资源上构建不同的应用程序。 还可以利用不同服务器甚至不同组织（ 混搭 ）上托管的资源来构建应用程序。

应用程序状态与资源状态

REST的无状态约束并不是说服务器不能维护任何状态，而只是说服务器不应该维护应用程序 （或会话）状态。

允许服务器维护其他状态。 实际上，如果没有，大多数服务器将完全无用。 想想没有书的亚马逊网上商店！ 我们称这个资源状态为区别于应用程序状态。

那么，我们如何在资源状态和应用程序状态之间划清界限？

资源状态是我们希望在同一用户的多个会话之间以及在不同用户的会话之间可用的信息。 资源状态最初可以由服务器（例如书）或客户端（例如书评）提供。

应用程序状态是与应用程序的一个特定会话有关的信息。 例如，我的购物车中的内容可以是应用程序状态。

请注意，这不是Amazon实施的方式。 他们将这种状态保留在服务器上。 这并不意味着亚马逊的人们不了解REST。 我用来购买的Web浏览器不够复杂，无法维护应用程序状态。 另外，他们希望我能够关闭浏览器并明天返回购物车。

此示例说明什么是应用程序，什么资源状态是设计决策。

应用程序状态与用户在驱动客户端时试图达到的目标有关。 我们在谈论REST API的状态图时所指的就是这种状态，而不是资源状态。

状态转移

应用程序状态是用户尝试实现目标时在客户端维护的所有信息。 此信息是根据客户端和服务器之间传输的资源状态逐个建立的。

资源状态作为表示进行传输，资源状态的特定序列化适合于包含在HTTP消息正文中 。

序列化受媒体类型中列出的规则支配。 媒体类型很多 ，有些则比其他媒体更成熟 。

由于客户端和服务器传输资源状态的表示形式，因此我们称其为表示状态传送 （REST）。

翻译自: https://www.javacodegeeks.com/2014/11/the-state-of-rest.html