HATEOAS标准/架构模式

Question

如果我是正确的，HATEOAS是一个架构模式，而不是描述一个客户应该如何发现关系。HATEOAS只是描述了服务器应该向客户端发送一个可发现的API。

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

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

从我的观点来看，这将允许我作为api作者定义这样的东西(有效的HATEOAS)：

符号"“表示超媒体控件的数组。

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

字符串可以从保留符号“✔”，“↯”和"±“开始。

如果超媒体字符串以"✔“开头，则允许客户端对URL执行安全的GET请求。该网址跟随"✔“符号，并被✔解码。

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

在我看来，这应该是有效的，还是我错过了什么？

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

Answer 1

没有像"HATEOAS“这样的标准或架构模式。有REST(具象状态传输)、架构样式、(样式、而不是模式或其他什么)，它包含几个约束。其中一个约束被称为-“超媒体作为应用程序状态的引擎”。

如果超媒体字符串以"✔“开头，则允许客户端对URL执行安全的GET请求。该网址跟随"✔“符号，并被✔解码。

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

它是由媒体类型定义的，而不是由诸如“如果URL跟随符号”之类的约定来定义的。