将 HATEOAS 用于 RPC 样式的命令是否 RESTful

Question

在 REST 中，资源由其 URI 标识，允许的操作仅限于 HTTP 可用动词。 RESTfull API 是一个统一接口，为 HTTP 上的资源提供基本的 CRUD 操作。

最后，REST 架构声明资源应包含超链接，以便客户端进一步遍历 API。 这称为 HATEOAS（超文本作为应用程序状态的引擎）。 超链接将客户端代码与接口实现细节分离。

使用 HATEOAS 链接以 RPC 样式传递针对资源的命令式命令是 RESTful 吗？ 我认为这不会破坏统一界面，因为链接中提供了所有信息。 考虑以下示例，其中操作不适合 HTTP 动词。

GET /foo/1

{ id: 1, foo: "foo", links: { self: "/foo/1", doAction: "/foo/1/do-action" } }

POST /foo/1/do-action

或者我应该只使用请求参数将命令信息传递给资源端点，还是 model 命令作为它自己的资源？

Answer 1

使用 HATEOAS 链接以 RPC 样式传递针对资源的命令式命令是 RESTful 吗？

REST是一种建筑风格； 如果您想了解它是如何工作的，您应该在使用该样式创建的应用程序中寻找类似物。 对于 REST，这些应用中最著名的是全球 Web。

因此，您的问题的答案来自于考虑您的情况与在 web 上实现有用工作的密切程度； 也就是说，通过超链接导航，直到我们找到正确的表格，填写数据，然后提交。

{ 
    id: 1,
    foo: "foo",
    links: {
        self: "/foo/1",
        doAction: "/foo/1/do-action" 
    }
}

因此，从 REST 的角度来看，问题变成了“通用组件如何知道doAction做什么？”

在 web 上，我们有一个针对 forms 的通用标准，因此表单的超媒体表示带有客户端为请求创建正确有效负载所需的信息。

在AtomPub中，标准定义了各种文档中链接关系的语义，因此任何通用的 atom 客户端都知道如何解释包含在响应中的数据。

（从某种意义上说，Atom 中链接关系的定义很像 HTML 中的 A 和 FORM 的定义；它们是通用的）。

因此，在您的上下文中，提示“doAction”应该通知客户端可以完成的一些有趣的事情（在此处发布猫视频）。 目标 uri对客户来说应该无关紧要； 它应该只是在被告知的地方发送请求。

这里的target-uri 的拼写根本不重要； 但是要考虑的一个有趣的情况是，当 target-uri 与您在其他地方使用的相同时会发生这种情况，例如：

{ 
    id: 1,
    foo: "foo",
    links: {
        self: "/foo/1",
        doAction: "/foo/1" 
    }
}

HTTP 在标准中内置了简单的缓存失效语义； 实际上，您的doAction目标告诉客户端，当操作成功时，哪个缓存表示将失效。