问题标签 [uniform-interface]

我有以下代码，我想知道为什么list.head.effects =这里需要这个部分。据我了解，统一访问原则表示该列表应该由返回list.head.effects，此时我可以访问该列表。但是要使作业真正起作用，我需要如下所示。会不会是它评估Entrance :: list.head.effects但没有在任何地方分配它？还是我在变幻的世界里太深了？

无论如何，有没有更好的方法来做到这一点？

维基百科有：

统一的界面

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

资源识别

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

通过这些表示来操纵资源

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

自我描述的消息

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

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

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

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

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

这让我觉得错了。与 URI 的外观或一致性无关，因为它是 URI 的使用方式（识别资源、通过表示、自描述消息和仇恨来操纵资源）。

我认为这根本不是统一接口的意思。它到底是什么意思？

通过考虑 REST 原则在 Web 中的应用。我正在做一个关于 REST 的案例研究，我对统一接口有一些疑问。我假设统一接口只有一个单一的 PROCESS 而不是 HTTP 动词（例如 get、post、put、delete、head、...）。这种使用传统 HTTP 动词的过程是否有任何潜在后果？

我已经在后端工作了一段时间，最近才开始在前端工作，这让我更接近端到端的 REST 实现。

更重要的是，REST 的一个重要原则是使其可发现和一致，以便客户端知道如何通用地处理资源（HATEOAS、JsonApi 等）。我一直在阅读这篇 Google 文章，其中有以下几点：

如果一个 API 简单直接地使用 HTTP，它只需要记录三四件事。（如果一个 API 需要您阅读大量文档来学习如何使用它，那么它可能没有使用 HTTP 作为统一 API。） HTTP API 的四个元素是：

1. 数量有限的固定、知名 URL。这些类似于数据库中表的名称。对于可选的额外信用，使所有固定 URL 都可以从一个 URL 中发现。

后来……

了解如何设计好的 HTTP/REST API 的人也很短缺。不幸的是，我们看到许多尝试采用面向实体的 HTTP/REST 样式的 API 示例，但由于没有始终如一地遵循模型，因此未能实现所有好处。一些常见的错误是：

1. 使用“本地标识符”而不是 URL 来编码实体之间的引用。如果 API 需要客户端替换 URI 模板中的变量来形成资源的 URL，那么它已经失去了 HTTP 统一接口价值的重要部分。构建对查询进行编码的 URL 是 URI 模板的唯一常见用途，它与 HTTP 作为统一接口的想法兼容。

我同意两者，但我看不到如何实现这一点。

所以这是场景：

• API 端点：
  • GET openapi.json / wadl / whatever-discovery-mechanism
  • GET /articles
  • GET /articles/$id
  • DELETE /articles/$id
  • ...
• 前端网址：
  • GET /site/articles- 显示文章列表/表格的页面
  • GET /site/articles/1- 带有用于编辑该文章的表单的页面

导航到/site/articles时，前端会知道调用/articlesAPI 端点——这是 Google 提到的“有限固定 url”之一。考虑到文章实体返回的链接，也可以删除/更新。通过客户端导航，前端还可以“重定向”到/site/articles/1.

棘手的部分是当用户直接导航到/site/articles/1- 页面如何知道调用/articles/$id而不构建 URL 本身（或以某种方式翻译它）？

这些是我看到的选项：

1. 构建 URL（这基本上是上面提到的“常见错误 1”）
2. 从发现链接构建 URL（先前选项的变体，仍然与 IMO 一样糟糕）
3. 在前端 URL 中编码实体“self”链接 我对此的担忧是：
   • 有点丑
   • 不安全（xsrf / 打开重定向 ...）
   • 它强制前端无论如何构建 URL（只有它理解）
4. 编码实体标识符（据我所知，它是“自我”链接），然后查找它/articles以调用返回的链接
   • 比3还要丑。
   • 足够安全
   • 乍一看似乎毫无意义...