web-services - 表示状态在 REST 中是什么意思？

Question

我一直在网上阅读以了解两个词的确切含义：

代表性国家

我有个疑问。我误解了这些术语。我想与一些人澄清对此的理解。

我的理解是，服务器中有一个资源。SO Rest 意味着，将此资源的某些表示状态传输给客户端。

如果服务器有资源 x，那么如果我们可以制作资源 x 的表示状态 y，并通过网络传输它就是 REST 的意思，这是正确的还是它的正确含义是什么。有人可以解释一下吗？

Answer 1

尽管 REST 是无状态的，但它的名称中包含状态转移。这让每个人都感到有些困惑。

无状态

当您在浏览器中打开网页时，您将充当服务消费者，而 www 服务器将充当服务提供者，为您提供网页服务。如果是正常连接，客户端和服务器都会进行握手并发起会话（称为 TCP 连接）。

之后，根据服务器和客户端的行为，状态将更改为 ESTABLISHED、IDLE、TIMEOUT 等。但在 REST 中，我们使用的是无状态的 HTTP 协议，这意味着服务器不会存储任何会话信息客户端。客户端负责发送服务器获得服务所需的所有详细信息，这意味着当我们 http://somedomain:8080/senthil/services/page1从服务器调用 URI 时，它有足够的关于客户端的详细信息来完全服务 page1。

状态转移

使用相同的示例，当您使用某个 URL 打开网页以查看服务器上的图像文件（资源）时，www 服务器将以某种格式向您（客户端）显示图像，即资源的表示（图像文件）。

在这个过程中，服务器的恒定资源状态（即存储在服务器数据库中的图像文件的状态）将以一种可以理解的格式，即客户端的应用程序状态，呈现给客户端。因此，资源状态相对于客户端将保持不变，只有资源的表示会改变，这反过来会改变应用程序的状态。

最后，隐式改变服务器和客户端状态的资源表示（图像如何显示给客户端）称为 REST。

Answer 2

具象状态转移是指转移“表象”。您正在使用资源的“表示”将位于服务器上的资源状态转换为客户端上的应用程序状态。

Answer 3

每个对象都有一些状态（数据）和行为（方法）。为了在特定时间实例将服务器上对象的状态传输到客户端，需要某种表示形式，例如 JSON 或 xml 或任何其他格式。

所以 REST 是关于创建对象当前状态的表示并通过网络传输该表示。

Answer 4

TL;博士

Representational state transfer或者简单地说 REST 是一个术语，用于以明确定义的格式交换数据以提高互操作性。通过应用某些约束，应该实现从客户端到服务器的解耦，这使得前者更健壮，而后者更灵活地适应变化。

资源表示是将资源当前状态映射到媒体类型定义良好的语法和结构的结果。因此，它与内容协商高度耦合，内容协商定义了就媒体类型达成一致以将资源状态转换为请求的表示（=语法和结构）的过程。

---

REST 可以被视为一种在分布式系统中将客户端与服务器/API 分离的技术，它使服务器端可以自由地根据需要发展和更改其结构，而不会破坏客户端实现。

为了获得如此强大的利益，需要具备几个先决条件，因为几乎没有什么是免费的。菲尔丁在这里定义了几个限制条件，他在他著名的博客文章中进一步阐明（和解释）了这些限制条件。如果客户端不遵循 REST 方法，服务器将无法实现这种自由，如果服务器不支持客户端，客户端将无法动态探索进一步的可能性。总之，双方需要遵循相同的原则。如果不严格遵循该方法，则服务器和客户端之间的直接耦合将保持不变，如果服务器要更改，这将导致失败。

但实际上是如何实现脱钩的呢？

首先，服务器应该通过包含客户端能够使用的 URI 来支持客户端完成其任务。让服务器提供客户端可以从客户端当前状态调用的所有 URI，从而消除了客户端对 API 和 URI 结构的先验知识的需要。

其次，服务器不应让客户端解释 URI，而应返回 URI 和链接关系名称。即，与其使用（和解释）类似 URI 的客户端http://server.org/api/orders应该使用类似new-order. 如果服务器将上面的 URI 更改为 ie http://server.org/api/new-orders，无论出于何种原因，使用链接关系名称的客户端仍将能够执行其任务，而直接使用 URI 的客户端将需要更新才能继续。

据我所知，目前还没有定义和记录此类链接关系名称的标准。对于集合链接，关系名称的语义，如、 、self和 prev似乎足够有意义，尽管更具体的领域喜欢或可能不喜欢。这种语义可以用特殊的媒体类型或新标准来描述。nextfirstlastorderproduct-xyz

到目前为止，这些要点解决了 HATEOAS 约束，但不幸的是，这还不是全部。根据菲尔丁的博客文章：

REST API 应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或定义扩展关系名称和/或现有标准媒体类型的超文本启用标记。

菲尔丁进一步评论说：

REST API 永远不应该有对客户端很重要的“类型化”资源。规范作者可以使用资源类型来描述接口背后的服务器实现，但这些类型必须是不相关的并且对客户端不可见。对客户端重要的唯一类型是当前表示的媒体类型和标准化关系名称。

类型化资源是客户端对内容有预先假设的资源。即，接收到http://server.org/api/user/sam+sample具有链接关系名称的 URI 的客户端user确定属于该资源的数据描述了一个人，因此可能会尝试application/json将资源数据的表示编组到Person对象。

类型化资源的问题在于，客户端对这些资源中包含的数据有某些预先分配的假设或知识，即用户资源可能因服务器而异。虽然一个服务器可能会将用户名公开为name其他服务器可能使用的属性firstName，lastName并且想要为每种可能性提供服务器的客户端几乎是不可维护的。此外，如果服务器曾经更改其逻辑客户端可能会以一定的可能性中断。为了应对这种耦合，应该使用媒体类型。

媒体类型是表示格式的人类可读文本描述，它定义了使用的语法以及包含在以该格式交换的文档中的可用元素的结构和语义。因此，遵循 REST 架构模型的应用程序应使用已建立或自定义的媒体类型来提高互操作性。不是直接耦合客户端和服务器，而是实际上都耦合到媒体类型。可以通过加载现有库或从头实现规范来提供对此类媒体类型的支持。如果支持，甚至可以通过插件动态加载此类媒体类型。

客户端和服务器应使用内容协商来就双方都理解的通用媒体类型格式达成一致，以交换资源的当前状态。内容协商是通过提供 HTTPAccept标头（和/或其兄弟之一）来实现的，该标头列出了客户端能够或愿意在请求中处理的 MIME 类型，并由服务器以所请求的格式之一进行响应，包括Content-TypeHTTP 响应标头通知客户端实际使用了哪种媒体类型表示或返回406失败响应。

Accept对于上面的 person 示例，客户端可以发送具有以下内容的 HTTP标头：application/vcard+json, application/hal+json;q=0.6, application/json;q=0.1到服务器，它要求服务器以列​​出的媒体类型之一定义的语法和结构返回资源的状态。它进一步指定客户端更喜欢接收根据application/vcard+json媒体类型描述规范格式化的状态，如果服务器不能接收，它应该更喜欢 hal+json 而不是传统的 json 语法。406服务器现在要么将当前资源的状态映射到请求的格式之一，要么在所有请求的媒体类型未知或状态无法转换为客户端支持的这种结构或默认表示时以适当的失败消息进行响应.

总而言之，REST 是一种通过依赖于定义良好的媒体类型来实现高互操作性的技术，并通过使用内容协商和 HATEOAS 等功能将客户端与服务器解耦。作为奖励，客户端将对更改变得健壮，因此通常需要较少的维护，而服务器则获得了能够进化和更改的好处，而不必担心一旦更改生效，客户端将无法与之交互。

某些事情，如标准化的有意义的链接关系名称、自定义的依赖于域的媒体类型和将状态转换为适用于媒体类型的表示的映射过程，需要首先设置，这是一项不平凡的任务 TBH，尽管一旦可用，它们就会提供上述好处。

Answer 5

从我的博客复制

REST 是关于创建对象当前状态（如数据库中的数据）的表示（如 JSON 或 xml 或任何其他格式）并通过网络传输该表示。休息是一组约束/约定。

资源与其表示分离，因此可以以各种格式访问其内容，例如 HTML、XML、纯文本、PDF、JPEG、JSON 等。有关资源的元数据可用并用于，例如，控制缓存、检测传输错误、协商适当的表示格式以及执行身份验证或访问控制

在底层，休息只不过是一系列原则的集合。

1. 通信应该是无状态的：服务器不应该存储任何状态。如果需要，它应该是消息的一部分

2. 状态应该是有代表性的：服务器的内部资源可以是一种形式，但它应该能够改变它的表现形式。一个 URI 引用的对象可以有不同的可用格式。不同的平台需要不同的格式。移动设备可能需要 JSON，而桌面设备可能需要 XML

3. 必须严格遵循 GET、POST、PUT 和 DELETE 等 HTTP 动词。

4. 资源应该是可寻址的：网络上的每个资源都应该有一个特定的地址（特定的 URI）

Answer 6

我认为关于 REST 架构风格的整个问题，围绕着理解，作者 Roy Fielding 在他的论文中提出了一套架构原则，用于构建基于 Hipertext 或超媒体范式。

我认为，这种范式是理解这一重要主题的核心关键。

在 Roy Fielding 提出的组织客户端-服务器应用程序架构的风格背后，我认为现代客户端-服务器应用程序有一个特定的想法，它由一种管理应用程序状态转换的引擎组成，其状态可能可扩展为无限的。

在这个愿景中，Ipertext\Ipermedia 是菲尔丁提出的整个建筑风格的中心，而让这种范式发挥作用的关键概念是“表征（状态）转移”。

我认为“具象”是指关于“转移”的概念，而不是关于“状态”的概念，即转移是具象的（具象类型的），也就是说，在我看来， “代表性国家转移”名称的主要原因。

因此，设计一个 Restful 应用程序，首先要设计一个基于组件网络的架构，每个组件都在客户端-服务器分层架构模型中与其他组件通信，向每个组件发送其状态的表示。

因此，前端，这个架构的第一个客户端，通过它的状态传输，显示一个或多个组件发送的状态的表示，它调用在统一一致的接口上而不是在“私有”api 上进行背书。

在作者看来，这种类型的应用程序可能会扩展到无限状态，因为它的状态不依赖于私有 api，而是依赖于该架构中所有代理共享的唯一标识符系统（如 URI） ，在一些动词上管理其状态的转换，以及在商定的共享表示传输系统上，或加号。

这个转换结束于它的表示通过构成“公共”api的动词与被调用的服务器组件通信，它应该属于组件客户端-服务器使用的无状态通信协议。

以这种方式，这种客户端-服务器组件交互包括使用无状态协议交换（传输、通信）组件状态的表示。

允许所有这些架构潜在地扩展到无限的核心概念是支持其架构的表示转移。

Answer 7

REPRESENTATIONAL STATE TRANSFER 的含义是 REST

RESTful 已将 DIRECT VERB 放入服务器

在实际考虑的例子中，放入 VERB 的值一般有 HTTP GET 和 POST

具有与 SOAP 不同的简单协议（非常复杂！）

如果答案不满意，请提供更详细的问题

REST 有很多讨论的话题，是很多博客和书籍的话题

Answer 8

想象一个状态图——下面就可以了。

如果这是一组网页，您将从学生的本科登录页面开始。根据图表，当您单击“下一步”链接时，它将带您进入新生页面 - 假设学生已经毕业。通过多次单击“下一步”，您可以到达最后一页。

当然，可能还有其他转换，例如“主页”，允许您跳转到默认页面。

网站的可见状态与服务器如何在内部实现这种关联无关——即内部状态。它可能涉及多个数据库、服务器等等。学生可能毕业，他/她的状态可能已通过其他方法更新。客户不知道这些细节——但总是可以期望获得一个连贯的可见状态（集合）供人类（或机器）消费。

另一个示例：当您查看此页面时，您处于 StackOverFlow Web 层次结构中特定可识别且可重现的“位置”。

因此，RESTful State 处理导航。