Representational State在REST中意味着什么？

Question

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

代表国家

我怀疑。我误解了这些条款。我想澄清一些人如何对此有所了解。

我的理解是，服务器中有一个资源。 SO Rest表示将此资源的某些表示状态转移到客户端。

如果服务器有资源x，那么如果我们可以创建资源x的表示状态y，并通过Web传输它是REST的意思，这是正确的还是正确的含义。有人可以解释一下这个。

Answer 1

虽然REST是无状态的，但它的名称中有状态转移。这对每个人来说都有点混乱。

的无状态 的

当您在浏览器中打开网页时，您将充当服务使用者，而www服务器将充当服务提供商，为您提供网页服务。如果是正常连接，则客户端和服务器都将执行握手并启动会话（称为TCP连接）。

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

州转移

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

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

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

Answer 2

代表性国家转移是指转移“陈述”。您正在使用资源的“表示”将服务器上的资源状态转移到客户端上的应用程序状态。

Answer 3

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

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

Answer 4

我认为关于REST架构风格的关注的整个问题，即理解，作者Roy Fielding在他的论文中，他在他的论文中提出了一套建立基于架构的架构原则。 hipertext或hipermedia范例。

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

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

在这个愿景中，Ipertext \ Ipermedia是Fielding提出的整个建筑风格的中心，允许这种范式工作的关键概念是代表性（状态）转移＆＃34;。

我认为＆＃34;具有代表性＆＃34;指的是关于＆＃34;转移＆＃34; 的概念，而不是关于＆＃34; state＆＃34;的概念，也就是说，转移是代表性的（代表性类型），在我看来，这是名称＆＃34;具象国家转移的主要原因＆＃34;。

因此，设计Restful应用程序时，首先要设计一个基于组件Web的体系结构，每个组件都与客户端 - 服务器分层体系结构模型中的其他组件通信，向每个组件发送一个表示形式其州。

因此，前端，这个架构的第一个客户端，通过其状态转换，显示由组件或组件发出的状态的表示，它称为在统一的一致接口上支持而不是＆＃ 34;私人＆＃34; API。

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

这种转换以其表示通过构成＆＃34; public＆＃34;的动词与被叫服务器组件的通信而告终。 api，应该属于组件client-server使用的无状态通信协议。

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

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

Answer 5

代表状态转移的含义是REST

RESTful已将DIRECT VERB放入服务器

在实际考虑的例子中，放入VERB的值通常是HTTP GET和POST

SIMPLE协议与SOAP非常相似（有很复杂！）

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

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

Answer 6

想象一下状态图 - 以下将会这样做。

如果这是一组网页，您可以从学生的本科目标网页开始。根据图表，当您点击＆＃34;下一步＆＃34;链接，它将带你到新生页面 - 假设学生已毕业。点击＆＃34; next＆＃34;多次，你到达最后一页。

当然，可能会有其他过渡，例如＆＃34; Home＆＃34;允许您跳转到默认页面。

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

另一个例子：当您查看此页面时，您处于一个特定的可识别且可重现的位置＆＃34;在StackOverFlow Web层次结构中。

因此，RESTful State处理导航。

Answer 7

<强> TL; DR

Representational state transfer或简称REST是用于以明确定义的格式交换数据以增加互操作性的术语。通过应用某些约束，应该实现从客户端到服务器的解耦，这使得前者更加健壮，后者更容易更改。

资源表示是应用从资源当前状态到媒体类型明确定义的语法和结构的映射的结果。因此，它与content-negotiation高度耦合，它定义了同意媒体类型以将资源状态转换为请求的表示（=语法和结构）的过程。

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

为了获得如此强大的利益，需要有几个先决条件，因为几乎没有任何免费的东西。菲尔丁在这里定义了一些约束，他在well known blog-post中进一步澄清（并解释）了这些约束。如果客户不遵循REST方法，并且客户端无法在服务器不支持客户端的情况下动态探索更多可能性，服务器将无法实现这种自由。简而言之，双方都需要遵循相同的原则。如果不遵循严格的方法，服务器和客户端之间的直接耦合将保持不变，如果服务器将要更改，将导致失败。

但实际上解耦是如何实现的？

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

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

据我所知，还没有标准，应该定义和记录这种链接关系名称。对于集合链接，self，prev，next，first和last之类的关系名称的语义似乎有足够的意义，尽管更具域名特征如{ {1}}或order可能不会。这种语义可以用特殊媒体类型或新标准来描述。

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

  

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

Fielding进一步表示：

  

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

typed resource是客户端预先设定内容的资源。即接收到具有链接关系名称product-xyz的URI http://server.org/api/user/sam+sample的客户端确定属于该资源的数据描述人，因此可能尝试将资源数据的user表示封送到application/json对象。

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

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

客户端和服务器应使用content negotiation来商定双方理解的公共媒体类型格式，以交换资源的当前状态。内容协商是通过提供HTTP lastName标头（和/或其中一个兄弟节点）来实现的，该标头列出了客户端能够或愿意处理的MIME类型，在请求中以及服务器响应其中一个请求的格式包括Accept HTTP响应标头，以通知客户端实际使用了哪种媒体类型表示或返回Content-Type失败响应。

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

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

需要首先设置标准化有意义链接关系名称，自定义域依赖媒体类型和将状态转换为媒体类型适用表示的映射过程等特定事项，这是一个非常重要的任务TBH，尽管一旦可用，它们提供上述提到的好处。

Answer 8

从我的blog

复制

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

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

在地面上，休息不过是一系列原则

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

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

3. HTTP动词（例如GET，POST，PUT和DELETE）必须严格遵守。

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