具象状态在 REST 中意味着什么?

我在网上到处找这两个词的确切含义:

代表州

我有疑问。我误解了这些术语。我想澄清了解一些人如何有好的想法这一点。

我的理解是,服务器中有一个资源。SO Rest 意思是,将这个资源的一些表示状态传递给一个客户端。

如果服务器有一个资源 x,那么如果我们可以使资源 x 的表示状态 y,并且通过网络传输它就是 REST 的意思,这是正确的还是正确的意思。谁能给我解释一下。

43374 次浏览

REST 的含义是 REST

RESTful 已将 DIRECTVERB 放入服务器

在实际考虑的例子中,VERB 中输入的值通常有 HTTPGET 和 POST

SIMPLE 协议非常不像 SOAP (非常复杂!)

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

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

REST 是指传递「申述」。您正在使用资源的“表示”来将服务器上的资源状态传输到客户机上的应用程序状态。

虽然 REST 是无状态的,但是它的名字中有状态传输。

无国籍

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

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

国家转移

使用同样的例子,当你打开一个网页,使用一些 URL 来查看一个图像文件(RESOURCE)在服务器上,www 服务器将显示你(客户端)在一些格式的图像,即 REPREENTATION 的 RESOURCE (图像文件)。

在这个过程中,服务器的常量 资源状态(即存储在服务器数据库中的图像文件的状态)将以一种可理解的格式(即客户端的 < em > 申请状态 )表示给客户端。因此,对于客户端,资源状态将保持不变,只有资源的表示形式会发生变化,这反过来又会改变应用程序状态。

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

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

我认为,这个范式是理解这个重要主题的中心关键。

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

在这个愿景中,Ipertext Ipermedia 是 Fielding 提出的整个体系结构风格的中心,允许这个范式工作的关键概念是“代表性(状态)转移”。

我认为“代表性”是指“转移”的概念,而不是“状态”的概念,也就是说,它是具有代表性的转移(具有代表性的类型) ,我认为,这是“ REST”这个名称的主要原因。

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

因此,这个体系结构的前端,第一个客户端,通过它的状态传输,显示组件或组件发送的状态的表示,它在统一的一致性接口上而不是在“私有”API 上调用背书。

在作者看来,这种类型的应用程序可以扩展到无限的状态,因为它的状态不依赖于私有的 API,而是依赖于这个体系结构中所有代理共享的唯一标识符系统(作为 URI) ,依赖于一些管理状态转换的动词,依赖于一个约定的共享表示传输系统,或者加号。

最后,通过组成“ public”api 的动词将其表示形式传递给被调用的服务器组件,这些动词应该属于组件客户机-服务器使用的无状态通信协议。

通过这种方式,这种客户机-服务器组件交互包括使用无状态协议交换(传输、通信)组件状态的表示。

而允许所有这些体系结构潜在地将自身扩展到无限的核心概念是认可其体系结构的表示转换。

设想一个状态图——下面的内容就可以了。

A simple state diagram courtesy LucidChart

如果这是一套网页,你会开始在 本科生登陆页的学生。根据图表,当你点击“下一步”链接,它会带你到 新生页-假设该学生已毕业。通过多次点击“下一步”,你就到达了最后一页。

当然,可能还有其他的过渡,比如“ Home”,允许您跳转到默认页面。

网站的可见状态与服务器如何在内部实现这种关联没有任何关系——这就是内部状态。它可能涉及多个数据库、服务器等等。学生可以毕业,他/她的身份可能已经通过其他方法更新。客户机不知道这些细节,但总是可以期望获得一致的可见状态(设置) ,以供人(或机器)使用。

另一个例子: 当你在看这个页面时,你在 StackOverFlow 网页层次结构中的一个特定的可识别和可重复的“位置”。

因此,RESTful State 处理导航。

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

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

DR

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

资源表示是将从资源当前状态到媒体类型的映射应用到定义良好的语法和结构的结果。因此,它与 内容-谈判高度耦合,内容-谈判定义了同意媒体类型的过程,以将资源状态转换为所请求的表示(= 语法和结构)。


REST 可以被看作是一种在分布式系统中将客户机与服务器/API 分离的技术,它给予服务器端自由发展和改变其结构以满足其需求,而不会破坏客户机实现。

为了获得如此巨大的利益,需要有几个先决条件,因为几乎没有什么是免费的。Fielding 在这里定义了一些约束,他在他的 著名的博客文章中进一步澄清(并解释)了这些约束。如果客户端不遵循 REST 方法,服务器将无法实现这种自由,如果服务器不支持 REST 方法中的客户端,客户端将无法动态探索进一步的可能性。简而言之,双方需要遵循相同的原则。如果不严格遵循这种方法,服务器和客户机之间将保持直接耦合,如果服务器将要发生更改,这将导致失败。

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

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

其次,服务器应该结合链接关系名称返回 URI,而不是让客户端解释 URI。即,客户端应该使用像 new-order这样的链接关系,而不是使用(和解释)像 http://server.org/api/orders这样的 URI。如果服务器将上面的 URI 更改为即 http://server.org/api/new-orders,不管出于什么原因,使用链接关系名称的客户端仍然能够跟踪他们的任务,而那些直接使用 URI 的客户端在继续之前需要更新。

据我所知,目前还没有标准,这样的链接关系名称应该定义和文档化。对于集合链接,关系名称(如 selfprevnextfirstlast)的语义似乎足够有意义,尽管像 orderproduct-xyz这样更具领域特性的名称可能没有意义。这种语义可以在特殊媒体类型或新标准中描述。

到目前为止,这些要点解决了 HATEOAS 的限制,但不幸的是,这还不是全部:

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

Fielding 进一步评论说:

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

类型化资源是一种资源,其中客户端对内容有一个预设。也就是说,接收到具有链接关系名称 user的 URI http://server.org/api/user/sam+sample的客户端确定属于该资源的数据描述了一个人,因此可以尝试将该资源数据的 application/json表示封送到 Person对象。

类型化资源的问题在于,客户端对此类资源中包含的数据有某些预先分配的假设或知识,即用户资源可能因服务器而异。一台服务器可能将用户名作为 name属性公开,而另一台服务器可能使用 firstNamelastName,并且希望服务每种可能性的客户机几乎是不可维护的。此外,如果服务器改变其逻辑客户端可能会中断与一定的可能性。应改为使用媒体类型来对付这种耦合。

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

客户端和服务器应该使用 内容协商来商定一种双方都能理解的通用媒体类型格式,以便交换资源的当前状态。内容协商是通过提供一个 HTTP Accept头(和/或其兄弟之一)来实现的,该头列出了客户端能够或愿意处理的 MIME 类型,在请求中,服务器以包括 Content-Type HTTP 响应头在内的一种请求格式响应,通知客户端实际使用了哪种媒体类型表示,或者返回一个 406故障响应。

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

总之,REST 是一种通过依赖定义良好的媒体类型来实现高互操作性的技术,并通过使用诸如内容协商和 HATEOAS 等特性来将客户机与服务器分离。作为回报,客户端将变得强大,因此总体上需要更少的维护,而服务器获得的好处是能够发展和变化,而不必担心客户端将无法与它互动,一旦变化已经启动。

首先需要建立一些东西,比如标准化的有意义的链接关系名称、定制的依赖于域的媒体类型以及将状态转换为媒体类型的适用表示的映射过程,这是一个非常重要的任务 TBH,尽管一旦可用,它们将提供上述好处。

从我的 博客复制

REST 是关于创建表示(如 JSON 或 xml 或任何其他格式)对象的当前状态(如数据库中的数据)并通过网络传输该表示。Rest 是约束/约定的集合。

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

在基础层面上,剩下的不过是一系列原则的集合

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

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

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

  4. 资源应该是可寻址的: 网络上的每个资源都应该有一个特定的地址(特定的 URI)

表示是特定资源的不同形式。例如,相同的数据可能被格式化为特定的媒体类型,如 XML 或 JSON,本地化为特定的书面语言或地理地区,以及/或压缩或以其他方式编码以便传输。基础资源在每种情况下都是相同的,但其表示形式不同。