HATEOAS 标准/架构模式

Question

如果我是正确的，HATEOAS 是一种体系结构模式并且没有描述客户应该如何发现关系。 HATEOAS 只是描述服务器应该向客户端发送可发现的 API。

采用 HATEOAS 时，api 作者可以定义客户端如何发现关系。

例如，如果没有像 hydra / hal / jsonapi 这样的标准，则不清楚 json 是否使用 "link"、“_link”、"links", "relations" json 文档中的字段来表示关系。

在我看来，作为 api 作者，这将允许我定义如下内容（有效的 HATEOAS）：

符号“”表示超媒体控件数组

超媒体控件由字符串表示。

字符串可以以保留符号“✔”、“↯”、“±”开头。

如果超媒体字符串以“✔”开头，则允许客户端对URL 执行安全的GET 请求。 URL 跟在“✔”符号之后，并进行了 rot13 解码。

{
    …
    "": [
       “✔uggc://.../traerf/snagnfl”
    ]
}

在我看来，这应该是有效的 HATEOAS，还是我漏掉了什么？

当然，在 HATEOAS 之上定义自己的标准是没有意义的。

Answer 1

没有像"HATEOAS"这样的标准或架构模式。 REST(Representational State Transfer) Architectural Style(Style not pattern or something) 包含多个约束。 约束之一被称为-"Hypermedia as the Engine of Application State"。

If the hypermedia string starts with "✔", the client is allowed to do a safe GET request to the URL. the URL follows the "✔" symbol and is rot13 decoded.

所有这些都是不相关的（纯设计），唯一重要的是选择超媒体类型（HTML、Atom、Collection+JSON 等）和超文本控件，如：

<表单方法="..." 操作="..."

由媒体类型定义，而不是由 "if the URL follows the symbol" 等约定...

HATEOAS 标准/架构模式

HATEOAS standards / architectural pattern

api

rest

json

hateoas