此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Data REST 4.4.0! |
元数据
本节详细介绍了基于 Spring Data REST 的应用程序提供的各种形式的元数据。
应用程序级配置文件语义 (ALPS)
ALPS 是一种数据格式,用于定义应用程序级语义的简单描述,其复杂性类似于 HTML 微格式。ALPS 文档可用作配置文件,以解释具有与应用程序无关的媒体类型(如 HTML、HAL、Collection+JSON、Siren 等)的文档的应用程序语义。这提高了配置文件文档跨媒体类型的可重用性。
https://tools.ietf.org/html/draft-amundsen-richardson-foster-alps-00
Spring Data REST 为每个导出的存储库提供了一个 ALPS 文档。它包含有关这两个 RESTful 转换的信息 以及每个存储库的属性。
Spring Data REST 应用程序的根目录是一个配置文件链接。假设您有一个应用程序同时具有 和 related ,则根
文档将如下所示:persons
addresses
{
"_links" : {
"persons" : {
"href" : "http://localhost:8080/persons"
},
"addresses" : {
"href" : "http://localhost:8080/addresses"
},
"profile" : {
"href" : "http://localhost:8080/profile"
}
}
}
如果您导航到 中的配置文件链接,则会看到类似于以下内容的内容:localhost:8080/profile
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/profile"
},
"persons" : {
"href" : "http://localhost:8080/profile/persons"
},
"addresses" : {
"href" : "http://localhost:8080/profile/addresses"
}
}
}
在根级别,是单个链接,不能提供多个应用程序配置文件。那
是您必须导航到以查找每个资源元数据的链接的原因。profile /profile |
如果您导航到并查看资源的配置文件数据,则会看到类似于以下示例的内容:/profile/persons
Person
{
"version" : "1.0",
"descriptors" : [ {
"id" : "person-representation", (1)
"descriptors" : [ {
"name" : "firstName",
"type" : "SEMANTIC"
}, {
"name" : "lastName",
"type" : "SEMANTIC"
}, {
"name" : "id",
"type" : "SEMANTIC"
}, {
"name" : "address",
"type" : "SAFE",
"rt" : "http://localhost:8080/profile/addresses#address"
} ]
}, {
"id" : "create-persons", (2)
"name" : "persons", (3)
"type" : "UNSAFE", (4)
"rt" : "#person-representation" (5)
}, {
"id" : "get-persons",
"name" : "persons",
"type" : "SAFE",
"rt" : "#person-representation"
}, {
"id" : "delete-person",
"name" : "person",
"type" : "IDEMPOTENT",
"rt" : "#person-representation"
}, {
"id" : "patch-person",
"name" : "person",
"type" : "UNSAFE",
"rt" : "#person-representation"
}, {
"id" : "update-person",
"name" : "person",
"type" : "IDEMPOTENT",
"rt" : "#person-representation"
}, {
"id" : "get-person",
"name" : "person",
"type" : "SAFE",
"rt" : "#person-representation"
} ]
}
1 | 资源属性的详细列表(标识为 )列出了名称
的属性。Person #person-representation |
2 | 支持的操作。此指示如何创建新的 .Person |
3 | 这 is ,它表示(因为它是复数形式)应该将 POST 应用于整个集合,而不是单个 .name persons person |
4 | 是 ,因为此操作可以更改系统的状态。type UNSAFE |
5 | is ,表示返回的资源类型将为 resource。rt #person-representation Person |
此 JSON 文档的媒体类型为 .这与之前的 JSON 文档不同,后者具有
媒体类型的 .这些格式是不同的,并受不同的规范约束。application/alps+json application/hal+json |
您还可以在检查集合资源时在集合中找到链接,如下例所示:profile
_links
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/persons" (1)
},
... other links ...
"profile" : {
"href" : "http://localhost:8080/profile/persons" (2)
}
},
...
}
1 | 此 HAL 文档再现了该系列。Person |
2 | 它有一个指向元数据的相同 URI 的配置文件链接。 |
同样,默认情况下,该链接提供 ALPS。但是,如果您使用 Accept
标头,则可以提供 .profile
application/alps+json
超媒体控件类型
ALPS 显示每个超媒体控件的类型。他们包括:
类型 | 描述 |
---|---|
语义 |
状态元素(如 、 和其他元素)。 |
安全 |
触发安全、幂等状态转换的超媒体控件(如 或 )。 |
幂等 |
触发不安全的幂等状态转换(如 或 )的超媒体控件。 |
不安全的 |
一个超媒体控件,用于触发不安全的、非幂等的状态转换(如 )。 |
在前面显示的 representation 部分中,来自应用程序的数据位被标记为 。该领域
是一个涉及 Safe to retrieve 的链接。因此,它被标记为 。超媒体操作本身映射到类型上
如上表所示。SEMANTIC
address
GET
SAFE
带投影的 ALPS
如果您定义了任何投影,它们也会列在 ALPS 元数据中。假设我们还定义了 和 ,它们
将出现在相关操作中。(有关这两种预测的定义和讨论,请参阅“预测”。也就是说,GET 将出现在整个集合的操作中,而 GET 将出现在单个资源的操作中。以下示例显示了
该小节的替代版本:inlineAddress
noAddresses
get-persons
...
{
"id" : "get-persons",
"name" : "persons",
"type" : "SAFE",
"rt" : "#person-representation",
"descriptors" : [ { (1)
"name" : "projection",
"doc" : {
"value" : "The projection that shall be applied when rendering the response. Acceptable values available in nested descriptors.",
"format" : "TEXT"
},
"type" : "SEMANTIC",
"descriptors" : [ {
"name" : "inlineAddress", (2)
"type" : "SEMANTIC",
"descriptors" : [ {
"name" : "address",
"type" : "SEMANTIC"
}, {
"name" : "firstName",
"type" : "SEMANTIC"
}, {
"name" : "lastName",
"type" : "SEMANTIC"
} ]
}, {
"name" : "noAddresses", (3)
"type" : "SEMANTIC",
"descriptors" : [ {
"name" : "firstName",
"type" : "SEMANTIC"
}, {
"name" : "lastName",
"type" : "SEMANTIC"
} ]
} ]
} ]
}
...
1 | 此时将显示一个新属性 ,其中包含一个具有一个条目 的数组。descriptors projection |
2 | 在 里面,我们可以看到 。它呈现 、 和 。
在投影内呈现的关系会导致内联包含数据字段。projection.descriptors inLineAddress address firstName lastName |
3 | noAddresses 提供包含 和 的子集。firstName lastName |
有了所有这些信息,客户端不仅可以推断出可用的 RESTful 转换,而且在某种程度上还可以推断出 与后端交互所需的数据元素。
将自定义详细信息添加到您的 ALPS 描述中
您可以创建显示在 ALPS 元数据中的自定义消息。为此,请创建 ,如下所示:rest-messages.properties
rest.description.person=A collection of people
rest.description.person.id=primary key used internally to store a person (not for RESTful usage)
rest.description.person.firstName=Person's first name
rest.description.person.lastName=Person's last name
rest.description.person.address=Person's address
这些属性定义要为资源显示的详细信息。它们更改 的 ALPS 格式,如下所示:rest.description.*
Person
person-representation
...
{
"id" : "person-representation",
"doc" : {
"value" : "A collection of people", (1)
"format" : "TEXT"
},
"descriptors" : [ {
"name" : "firstName",
"doc" : {
"value" : "Person's first name", (2)
"format" : "TEXT"
},
"type" : "SEMANTIC"
}, {
"name" : "lastName",
"doc" : {
"value" : "Person's last name", (3)
"format" : "TEXT"
},
"type" : "SEMANTIC"
}, {
"name" : "id",
"doc" : {
"value" : "primary key used internally to store a person (not for RESTful usage)", (4)
"format" : "TEXT"
},
"type" : "SEMANTIC"
}, {
"name" : "address",
"doc" : {
"value" : "Person's address", (5)
"format" : "TEXT"
},
"type" : "SAFE",
"rt" : "http://localhost:8080/profile/addresses#address"
} ]
}
...
1 | 映射到整个表示中的值。rest.description.person |
2 | 映射到属性的值。rest.description.person.firstName firstName |
3 | 映射到属性的值。rest.description.person.lastName lastName |
4 | 的值 maps 到属性,该字段通常不显示。rest.description.person.id id |
5 | 映射到属性的值。rest.description.person.address address |
提供这些属性设置会导致每个字段都有一个额外的属性。doc
Spring MVC(这是 Spring Data REST 应用程序的本质)支持语言环境,这意味着您可以捆绑多个 属性文件。 |
JSON 架构
JSON Schema 是 Spring Data REST 支持的另一种形式的元数据。根据他们的网站,JSON Schema 具有以下优势:
-
描述您现有的数据格式
-
清晰、人可读和机器可读的文档
-
完整的结构验证,可用于自动化测试和验证客户提交的数据
如上一节所示,您可以通过从根 URI 导航到链接来访问此数据。profile
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/profile"
},
"persons" : {
"href" : "http://localhost:8080/profile/persons"
},
"addresses" : {
"href" : "http://localhost:8080/profile/addresses"
}
}
}
这些链接与前面显示的相同。要检索 JSON 架构,您可以使用以下标头调用它们:。Accept
application/schema+json
在这种情况下,如果您运行 ,您将看到类似于以下内容的输出:curl -H 'Accept:application/schema+json' localhost:8080/profile/persons
{
"title" : "org.springframework.data.rest.webmvc.jpa.Person", (1)
"properties" : { (2)
"firstName" : {
"readOnly" : false,
"type" : "string"
},
"lastName" : {
"readOnly" : false,
"type" : "string"
},
"siblings" : {
"readOnly" : false,
"type" : "string",
"format" : "uri"
},
"created" : {
"readOnly" : false,
"type" : "string",
"format" : "date-time"
},
"father" : {
"readOnly" : false,
"type" : "string",
"format" : "uri"
},
"weight" : {
"readOnly" : false,
"type" : "integer"
},
"height" : {
"readOnly" : false,
"type" : "integer"
}
},
"descriptors" : { },
"type" : "object",
"$schema" : "https://json-schema.org/draft-04/schema#"
}
1 | 导出的类型 |
2 | 属性列表 |
如果您的资源具有指向其他资源的链接,则有更多详细信息。
您还可以在检查集合资源时在集合中找到链接,如下例所示:profile
_links
{
"_links" : {
"self" : {
"href" : "http://localhost:8080/persons" (1)
},
... other links ...
"profile" : {
"href" : "http://localhost:8080/profile/persons" (2)
}
},
...
}
1 | 此 HAL 文档再现了该系列。Person |
2 | 它有一个指向元数据的相同 URI 的配置文件链接。 |