Representational State在REST中意味着什么？

Question

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

代表国家

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

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

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

Answer 1

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

无状态

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

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

国家转移

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

在此过程中,服务器的恒定资源状态(即存储在服务器数据库中的图像文件的状态)将以可理解的格式表示给客户端,即客户端的应用程序状态.因此,资源状态将相对于客户端保持不变,并且仅资源的表示将改变,这反过来将改变应用程序状态.

最后,资源的表示(图像如何显示给客户端)隐含地改变服务器和客户端的状态,称为REST.

Answer 2

具象国家转移是指转移"陈述".您正在使用资源的"表示"将服务器上的资源状态转移到客户端上的应用程序状态.

Answer 3

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

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

Answer 4

长话短说

\n

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

\n

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

\n\n

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

\n

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

\n

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

\n

首先，服务器应该通过包含客户端能够使用的 URI 来支持客户端执行其任务。让服务器提供客户端可以从客户端当前状态调用的所有 URI，这样客户端就不需要预先了解 API 以及 URI 的结构。

\n

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

\n

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

\n

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

\n

\n

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

\n

\n

菲尔丁进一步评论说：

\n

\n

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

\n

\n

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

\n

类型化资源的问题在于，客户端对此类资源中包含的数据具有某些预先分配的假设或知识，即用户资源，但可能因服务器而异。虽然一台服务器可能将用户名公开为name另一台服务器可以使用的属性firstName，lastName并且想要提供服务器的客户端每种可能性几乎是无法维护的。此外，如果服务器改变其逻辑，客户端就有可能崩溃。为了解决这个问题，应该使用耦合介质类型。

\n

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

\n

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

\n

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

\n

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

\n

需要首先设置某些东西，例如标准化的有意义的链接关系名称、自定义的与域相关的媒体类型以及将状态转换为媒体类型适用表示的映射过程，这是一项艰巨的任务，尽管一旦可用，它们就会提供上述好处。

\n

Answer 5

从我的博客复制的

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

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

在底层，休息只不过是原则的集合

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

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

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

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