在什么包含对"REST"这个词及其含义的误解

Question

确定什么是真正的RESTFull应用程序和/或api并不总是很容易,因为对于REpresentational State Transfer架构风格的含义和范围存在一种误解.

最初,我对于什么来说很麻烦,这个形容词"REpresentational"的首字母缩略词REST引用了.这是因为"代表性国家"听起来不太好......

此外,我对这种建筑风格的作者罗伊菲尔丁的博客文章印象深刻,他对基于http动词的api经常出现的误解感到非常失望,特别是他抱怨客户端和客户之间的耦合.这些api的服务器有关其名称和数据结构的信息.

博客文章参考:http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

我想尝试只给出关于REST arch的理论解释.风格,我想知道其他观点.

Answer 1

第一部分

我的主要目标是将注意力集中在名称"代表性国家转移"的原因上.

我认为关于REST的大多数误解都属于形容词"代表性".大多数人认为"代表性"一词与资源状态有关,因此构建应用程序专注于对象结构以与通信客户进行通信/转移......但我认为重点是"转移",它是转移到"代表性的,因此重要的设计应用程序(或api)利用REST网络系统的"代表性"能力,以支持客户端 - 服务器组件之间的传输.

为了弄清楚REST架构风格的关注的整个问题,需要理解作者Roy Fielding打算在他的论文中提出一套基于hipertext或hipermedia范例构建架构的架构原则,以及因此,这种范式是理解这一重要主题的核心关键.

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

在这个愿景中,Ipertext\Ipermedia是Fielding提出的整个建筑风格的中心,允许这种范式工作的关键概念是"代表性(状态)转移".

因此,我们可以理解为什么"代表性"这个词指的是关于"转移"的概念,而不是关于"状态"的概念.因为转移是代表性的(代表性类型),这意味着它是管理"转移"并且依赖于客户端 - 服务器交互的系统,给出关于表示的一些标准指示,即媒体类型的概念(或REST的Web实现中的MIME),在我看来,这是"Representational State Transfer"这个名称的主要原因.

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

因此,前端,这个架构的第一个客户端,通过其状态转换,显示由组件或组件发出的状态的表示,它称为在统一的一致接口上支持而不是在"私有"api上.

在作者的脑海中,这种类型的应用程序可能可扩展到无限状态,因为它的状态不依赖于私有api,而是依赖于此体系结构中所有代理共享的univoque标识符系统(作为URI) ,用一些动词来管理其州的转移和商定的共享代表性转移系统,或者加上.

这种转换以其表示通过组成"公共"api的动词与被叫服务器组件的通信而结束,该动词应该属于客户端 - 服务器组件所使用的无状态通信协议.

以这种方式,该客户端 - 服务器组件交互包括基于无状态协议的使用来交换(传送,传送)组件状态的标准化表示(媒体类型).

允许所有这些体系结构潜在地扩展到无限的核心概念是组件的资源结构和名称与其客户端识别和表示(代表性传输)的分离.

第二部分

有关mediatype和RESTful应用程序构建的更多详细信息

我认为Fielding最初的直觉是,在分布式应用程序体系结构中允许客户端和服务器组件之间完全解耦并且无限可扩展的关键特性是开放和不断发展的标准表示集的定义,因此这些组件交换这种表示的能力以及客户解释它们的能力.

这就是"代表性转移"的原因!

即,基于标准化的rappresentations进行转移.相反,"state"正是以标准方式表示的,因为任何支持REST原则的客户端组件都理解它,并允许表示本身成为包含其mediatype表示的状态转换的引擎,也是标准信息处理,它们应该引用与客户端 - 服务器通信协议相关的一小组标准动词.

因此,要构建遵循标准REST并因此遵循RESTful的应用程序(或从REST的角度来看连接器),意味着:

1. 为自己的资源设计uri;

2. 使这些uri始终可用于发送给客户的陈述;

3. 专注于设计最合适的媒体类型表示,以支持自己的应用程序流,因此相同的状态转换.

这意味着支持任何类型的设备上的任何类型的媒体,并且还支持任何类型的交互系统或过渡状态(例如,不仅是用户的自动化系统)

Answer 2

虽然我认为这篇文章显然更适合程序员，但由于这是一个一般性的概念讨论，我会尝试试一试。

对我来说，REST 是将当前包含在特定资源中的状态或数据从服务器传输到客户端，反之亦然。这种传输由客户端通过调用某些操作来初始化，底层通信协议提供，在资源上。表示方面现在是状态/数据的返回样式/风格/类型。如果客户端请求类似的内容，Accept: "application/hal+json", "application/json", "text/html"则直接要求服务器以三种格式中的任何一种格式（优先使用前导格式）来表示状态，服务器可以根据他的能力决定返回哪一种。还可以指定某些权重偏好以提高服务器返回此媒体类型而不是其他更一般的媒体类型的可能性。

REST 的简单性实际上很难在现实中实现，稍后会详细介绍。除了Roy Fielding 设置的一些架构约束之外，给定的链接还包括为了调用服务或 API RESTful 必须遵守的进一步列表，这些列表总结在以下列表中：

• API 应该遵守而不是违反底层协议。尽管 REST 大部分时间通过 HTTP 使用，但它不限于此协议。

• 强烈关注资源及其通过媒体类型的呈现。

• 客户不应该对 API 中的可用资源或其返回状态（“类型化”资源）有初步的了解或假设，而是通过发出的请求和分析的响应即时了解它们。这使服务器有机会在不破坏客户端实现的情况下轻松移动或重命名资源。

特别是 Roy Fielding 给出的最后一条规则经常被违反，因为当端点被明确地编码到客户端/应用程序中时，不允许客户端发现资源。此外，返回的类型通常是预先分配的。这导致 StackOverflow 上出现了大量与 URI 设计相关的问题，因为 URI 需要携带语义以便开发人员将它们放入客户端。

但媒体类型通常仅限于仅支持application/json或application/xml尽管它们不携带任何实际内容的语义。XML 专门设计为可扩展的，因此名称中带有 X。已经有很多基于 XML 的特殊类型，严格的框架通常只返回，application/xml这给客户端带来了了解响应语义含义的负担。

简单明了XML，JSON但是不会在实际内容上传达任何语义或定义支持客户理解的规则。它们只是描述客户端可以用来发现响应包含哪些元素以及它们包含哪些数据的语法，仅此而已。

通常建议使用 Atom/RSS 和 Json-HAL 来至少增强 HATEOAS 要求，因为它们提供到其他资源的链接，因此帮助客户端从语义上理解某个字符串必须被解释为它可以采取行动的进一步资源。尽管如此，客户端仍然不知道它实际处理的数据是什么。因此，应该开发特殊的媒体类型来支持客户端理解数据的全部内容——它们可能对相同的资源状态有不同的风格，即一种只给出资源状态的概述，而另一种媒体类型可能包含全套资料。

在我看来，这导致 Fielding 发表以下声明：

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

REST 试图引入的是从客户端到特定 API 集的明确解耦，就像 Web 浏览器不耦合到特定 Web 服务器一样。Web 浏览器能够在不中断的情况下呈现大量填充了图像或其他媒体类型的 HTML 页面。通过让客户端从基本 URL 开始，然后通过解释响应探索新的可能性来实现解耦。因此，HATEOAS 是通过服务器在先前请求中提供的链接来驱动客户端状态更改的原因。因此，服务器端的更改不会阻止任何真正的 RESTful 客户端，因为它们只会使用从先前响应中学到的东西。期望资源 X 位于路径 Y 并具有状态 Z 的客户端将非常确定地在服务器更改时中断。

对我来说，媒体类型是客户的知识库，并教她如何处理声明属于这种类型的特定文档。浏览器 ie 将呈现一个 HTMl 页面，因此它实际上是人类可读的。它还将使用 JavaScript 代码和注册事件动态更改表示。某些下载的字节可能会显示为图片，有些会被解释为视频，而其他类型可能会产生处理内容的某个对象（如某些视频播放器、flash 播放器或小程序）。

现在现实世界的问题是：如何编写任意客户端能够实际理解的媒体类型。任意我的意思是像一个自动化系统，它没有 API 或服务的先验知识，因此必须通过请求/响应来学习一切。由于状态及其表示可能有多种不同的风格，因此教客户端如何解释数据是一件困难的事情。数据的语义处理仍然是一个巨大的研究领域。自动化系统需要知道某些字符串具有某种语义，并且服务器返回的模板 URI 中的某些内容需要满足该语义的输入。

可以在IANA找到或多或少知名的注册媒体类型列表。在可能的情况下，建议使用这些媒体类型中的一种（如果合适）以避免重新发明轮子。然而，某些用例可能需要自定义格式，因此需要额外的开销（设计、实施并最终在 IANA 注册媒体类型可能需要一些时间）。

作为对这个缺点的反应，许多实现者尝试走简单的路线，将知识放入客户端，然后与 API 紧密耦合，并且不会轻易对 API 本身的变化做出反应。对于我们人类来说，掌握 URI 的意图是相当简单的，因此我们坚持使用干净的 URI-API。用户有一定的预先假设（基于命名或一些文档）API 的功能，因此将 REST 简化为营销术语。

很多人的误解是，就像 Fielding 所说的那样，在 HTTP 上工作的 API 被认为是 RESTful。此外，Richardson 成熟度模型在这个问题上并没有多大帮助，而且 StackOverflow 社区将与 API over HTTP 以某种方式相关的所有内容都视为 REST。