REST - 统一接口到底是什么意思？

Question

Wikipedia has:

统一界面

统一接口约束是任何 REST 服务设计的基础。[14]统一的接口简化并解耦了架构，使每个部分都可以独立发展。该接口的四个指导原则是：

资源识别

在请求中标识单个资源，例如在基于 Web 的 REST 系统中使用 URI。资源本身在概念上与返回给客户端的表示是分开的。例如，服务器可以从其数据库中以 HTML、XML 或 JSON 的形式发送数据，这些都不是服务器的内部表示，无论如何都是同一个资源。

通过这些表示来操纵资源

当客户端持有资源的表示，包括任何附加的元数据，它有足够的信息来修改或删除资源。

自我描述信息

每条消息都包含足够的信息来描述如何处理该消息。例如，调用哪个解析器可以由 Internet 媒体类型（以前称为 MIME 类型）指定。响应还明确指出它们的可缓存性。

超媒体作为应用程序状态的引擎（A.K.A. HATEOAS）

客户端仅通过服务器在超媒体内动态识别的动作（例如，通过超文本中的超链接）进行状态转换。除了应用程序的简单固定入口点外，客户端不假定任何特定资源可用于任何特定资源，而不是先前从服务器接收到的表示中描述的资源。

我正在听一个关于这个主题的讲座，讲师说：

“当有人使用我们的 API 时，如果您能够获取客户对象并且您知道有订单对象，那么您应该能够以与获取客户对象相同的模式获取订单对象。这些 URI 看起来会很像。”

这让我觉得是错误的。 与其说是 URI 的外观或一致性，不如说是使用 URI 的方式（识别资源，通过以下方式操作资源）陈述、自我描述的消息和仇恨）。

我认为这根本不是统一接口的意思。究竟是什么意思？

Answer 1

使用接口将类与其依赖项的实现分离是一个相当古老的概念。在 REST 中，您使用相同的概念将客户端与 REST 服务的实现分离。为了定义这样的接口（客户端和服务之间的契约），您必须使用标准。这是因为如果您想要一个互联网规模的 REST 服务网络，您必须强制执行全局概念，例如标准，以使它们相互理解。

• 资源识别 - 您使用 URI (IRI) 标准来识别资源。在这种情况下，资源是 Web 文档。

• 通过这些表示操作资源 - 您使用 HTTP 标准来描述通信。因此，例如 GET 意味着您要检索有关 URI 标识资源的数据。您可以使用 HTTP 方法和 URI 来描述操作。

• 自描述消息 - 您使用标准 MIME 类型和（标准）RDF vocabs 使消息自描述。因此客户端可以通过检查语义来找到数据，而不必知道服务使用的应用程序特定的数据结构。

• 超媒体作为应用程序状态的引擎（又名 HATEOAS）- 您使用超链接和可能的 URI templates 将客户端与特定于应用程序的 URI 结构分离。您可以使用语义注释这些超链接，例如IANA link relations，所以客户会明白他们的意思。

Answer 2

任何 ReSTful 架构都应遵守的统一接口约束实际上意味着，除了数据之外，服务器响应还应宣布可用的操作和资源。

在chapter 5 of his dissertation 中，Roy Fielding（ReST 架构风格的创始人）指出，使用统一接口的目的是：

简化和改进全局架构和交互的可见性

换句话说，查询资源应该允许客户端在事先不知道的情况下请求其他操作和资源。

JSON-API 规范就是一个很好的例子：

{
  "links": {
    "self": "http://example.com/articles",
    "next": "http://example.com/articles?page[offset]=2",
    "last": "http://example.com/articles?page[offset]=10"
  },
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!"
    },
    "relationships": {
      "author": {
        "links": {
          "self": "http://example.com/articles/1/relationships/author",
          "related": "http://example.com/articles/1/author"
        },
      },
      "comments": {
        "links": {
          "self": "http://example.com/articles/1/relationships/comments",
          "related": "http://example.com/articles/1/comments"
        }
      }
    },
    "links": {
      "self": "http://example.com/articles/1"
    }
  }]
}

只要分析这个单一的响应，客户就知道：

1. 查询了什么（本例中为articles）
2. 如何结构化文章对象（id、title、author、comments）
3. 如何检索相关对象（即author、comments 列表）
4. 还有更多文章（10，基于当前响应长度和分页链接）

我希望这会有所帮助。
对于那些对这个话题充满热情的人，我强烈推荐阅读Roy Thomas Fielding's dissertation！

Answer 3

您的问题有点宽泛，您似乎要求重述您的定义。您是在寻找示例，还是您不了解具体说明的内容。

我同意以下内容：

这些 URI 看起来很像

根本上是错误的。为了满足统一接口约束，URI 不需要看起来彼此相似。需要提供一种统一的方式来发现标识资源的 URI。这种统一的方式对每种消息类型都是唯一的，并且必须有一些约定的格式。例如，在 HTML 中，一个文档资源通过一个简单的标签链接到另一个文档资源：

<a href="URI of related resource" rel="defined relationship">fallback relationship</a>

HTTP 服务器将 html 作为文本/html 资源类型返回，浏览器有约定的解析方式。锚标记是具有相关资源唯一标识符的超媒体控件 (HATEOAS)。

唯一没有涉及的一点是操纵。 HTML 有另一个很棒的例子，form 标签：

<form action="URI" method="verb">
  <input name=""></input>
</form>

同样，浏览器知道如何解释此元信息以定义在 URI 处作用的资源的表示。不幸的是，HTML 只允许您对动词进行 GET 和 POST...

在基于 JOSN 的服务中更常见的是，当您检索 Person 资源时，很容易操纵该表示，然后将其 PUT 或 PATCH 直接返回到它的规范 URL。修改它不需要预先存在的资源知识。现在，当我们编写客户端代码时，我们都会被这样一种想法所包围，即我们实际上确实需要在使用它之前知道形状……但这实际上只是为了使我们的解析器高效且简单。我们可以制作解析器来分析资源每个部分的语义，并通过解释修改的意图来修改它。 IE：使人大 10 岁的命令将解析资源以查找年龄，识别年龄，然后将 10 年添加到该值，然后将该资源发送回服务器。拥有期望年龄位于 $.age 的 JSON 路径的代码是否更容易？绝对...但不是特别需要。

Answer 4

好的，我想我明白这意味着什么。

来自菲尔丁的论文：

REST 架构风格与其他基于网络的风格的主要区别在于它强调组件之间的统一接口（图 5-6）。通过将软件工程的通用性原则应用于组件接口，简化了整个系统架构并提高了交互的可见性。

他是说组件之间的接口必须相同。 IE。客户端和服务器以及任何中介之间，所有这些都是组件。