我们打算使用Spring-HATEOAS通过HAL / JSON来丰富我们的界面与超媒体信息。
我们想知道的是，如何在链接之后提供足够的元信息，以供我们在资源中查找到的信息。
我确定了发布此类信息的不同方法，一种是资源的内容类型，另一种是配置文件。
但是两者都不允许任何形式的多态性。
假设我们对一个气象站建模，该气象站的温度为风和光传感器。在我的概念中，我将链接这三个传感器：
"item" : [
{ "href" : ".../sensors/1" } // temperature
{ "href" : ".../sensors/2" } // wind
{ "href" : ".../sensors/3" } // light
]
这意味着它们是我的传感器集合（我的气象站是其中的一部分）。
向我的气象站用户提供以下元信息：
因此在代码中：
class TemperatureSensor extends Sensor
class WindSensor extends Sensor implements DirectionalSensor
class LightSensor extends Sensor implements DirectionalSensor, SprectralSensor
如何使用Spring-HATEOAS或直接使用HAL向用户提供这些信息？
我确定了发布此类信息的不同方法，一种是资源的内容类型，另一种是配置文件。
通常，媒体类型定义了如何处理有效负载，但不一定定义其内容所涉及的对象或类型。即收到HTML有效负载后，您不一定知道页面包含用户信息或类似信息，除非您在标记中存在某些语义注释。所有HTML定义了一组有效元素，这些元素如何嵌入有效负载中（即<element>...</element>或<element/>），它们支持哪些属性，以及何时允许添加哪些元素，例如某些元素，例如因为列表项标签<li>仅作为无序列表<ul>的一部分或与之对应的顺序列表<ol>是有意义的。
关于配置文件，根据RFC 6906
定义配置文件不是为了更改资源表示本身的语义，而是允许客户端了解除媒体类型所定义的语义之外的与资源表示相关的其他语义（约束，约定，扩展名）。以及其他可能的机制。
因此，这是在媒体类型处理器上设置的配置选项，取决于指定的配置文件，它可能会应用其他验证规则，允许某些元素出现在某些元素等中。即HTML4.01向<head>元素添加了配置文件，以便了解此配置文件的搜索引擎知道author，date，keyword和copyright的元信息将存在，可以直接使用而不是试图直接从身体解析该信息。
HAL支持media-type definitions和link objects上的配置文件规范。
...如何在链接后提供关于要在资源中找到的内容的足够的元信息。
在HTML中，通常通过向链接上下文添加附加文本来提示用户调用链接可能会返回什么，这些附加文本概括了该目标或图像的内容，这些内容向用户表达了对用户的承受能力。对于人类来说，这通常很容易理解，尽管对于自动化过程而言，此类元信息通常难以处理和采取行动。与其使用自由文本或图像来表达目标与当前内容的关系，不如使用链接关系来表达这一点。]
...应用程序将定义其使用的链接关系类型以及可能在其中发生的序列化。例如，应用程序“ Web浏览”在HTML链接序列化（以及可选的链接标题字段）中寻找“样式表”链接关系类型，而应用程序“ AtomPub”使用“ edit”和“ edit-media” Atom序列化中的链接关系。
Web链接还描述了链接关系不仅描述了简单的语义，而且还描述了特定的属性或行为。更正式地讲，它们描述了当前上下文与其他资源的关系。
Wikipedia将链接关系描述为：
链接关系是附加到超链接的描述性属性，用于定义链接的类型或源资源和目标资源之间的关系。该属性可以由自动化系统使用，也可以以其他方式呈现给用户。
此类链接关系应基于standardized terms或使用extension mechanism，即dublin-core。 Microformats还列出了HTML5中的许多常用关系名称。尽管链接关系一定不能限制当前文档的处理或目标表示类型的可用性，但是它们可以指定目标资源的某些行为或属性，即资源支持某些HTTP方法或某些媒体类型格式的支持。必填。
一个链接可能分配了多个不同的链接关系名称。不了解某个链接关系名称的客户端应忽略该名称，而只能对自己知道并支持的名称进行操作。基本上，这仅允许根据需要向URI上下文添加尽可能多的关系名称。这类似于语义Web，语义Web上在主语和宾语之间可能存在多个谓词，并且存在进一步的关系，这些关系表明谓词与另一个谓词表达相同，因此可以互换使用。
HAL开箱即用地支持链接关系，并在顶部添加CURIE，这是另一个保留的链接关系名称本身，它在资源文档的位置提示客户。 RFC 8288定义的链接关系扩展不一定需要指向文档，因此客户端不应尝试[]
... "links": { "self": { "href": "/weatherstation" }, "curies": [{ "name": "ws", "href": "http://api.weatherstation.com/docs/rels/{rel}", "templated": true }], "ws:sensors": [ { "href": "../sensors/1", "title": "temperature" }, { "href": "../sensors/2", "title": "wind" }, { "href": "../sensors/3", "title": "light" } ], "ws:unidirectional": { "href": "../sensors/1", "title": "temperature" }, "ws:directional": [ { "href": "../sensors/2", "title": "wind" }, { "href": "../sensors/3", "title": "light" } ], "ws:spectral": { "href": "../sensors/3", "title": "light" }, ... "http://api.weatherstation.com/rel/sensors": [ { "href": "../sensors/1" }, { "href": "../sensors/2" }, { "href": "../sensors/3" } ], "http://api.weatherstation.com/rel/unidirectional": { "href": "../sensors/1" }, "http://api.weatherstation.com/rel/directional": [ { "href": "../sensors/2" }, { "href": "../sensors/3" } ], "http://api.weatherstation.com/rel/spectral": { "href": "../sensors/3" } }在这一点上，我不确定100％居里人是否还表达了链接关系还是只是表达了资源的文件，因此我将样本划分了一点。从理论上讲，它们本身应该能够成为有效的链接关系名称，在这种情况下，可以跳过后面的定义，因为HAL处理器将按照RFC 8288的要求将它们解析为完整的URI。
虽然Web链接将允许链接关系，例如：
Link: <../sensors/3>; rel="http://api.weatherstation.com/rel/sensors http://api.weatherstation.com/rel/directional http://api.weatherstation.com/rel/spectral"在同一URI上定义了所有3个属性，我不确定这是否也可以直接在HAL中使用。
居里支持记录在reference documentation中，您基本上只需要在配置中添加
CurieProviderbean。该居里提供者可以使用您通过RelProvider定义的所有未注册链接关系。可以通过new Link("/some-target", IanaLinkRelations.NEXT)轻松添加已注册的链接关系，例如，如here中所述>