来自环境端点的默认JSON格式对于Spring应用程序的消费是完美的，因为它直接映射到Environment抽象。如果您喜欢，可以通过向资源路径（“.yml”，“.yaml”或“.properties”）添加后缀来使用与YAML或Java属性相同的数据。这对于不关心JSON端点的结构的应用程序或其提供的额外的元数据的应用程序来说可能是有用的，例如，不使用Spring的应用程序可能会受益于此方法的简单性。
YAML和属性表示有一个额外的标志（作为一个布尔查询参数resolvePlaceholders提供）），以标示Spring${…}形式的源文档中的占位符，应在输出中解析可能在渲染之前。对于不了解Spring占位符惯例的消费者来说，这是一个有用的功能。
注意使用YAML或属性格式存在局限性，主要是与元数据的丢失有关。JSON被构造为属性源的有序列表，例如，名称与源相关联。即使源的起源具有多个源，并且原始源文件的名称丢失，YAML和属性表也合并成一个映射。YAML表示不一定是后台存储库中YAML源的忠实表示：它是由平面属性源的列表构建的，并且必须对键的形式进行假设。
服务纯文本
您的应用程序可能需要通用的纯文本配置文件，而不是使用Environment抽象（或YAML中的其他替代表示形式或属性格式）。配置服务器通过/{name}/{profile}/{label}/{path}附加的端点提供这些服务，其中“name”，“profile”和“label”的含义与常规环境端点相同，但“path”是文件名（例如log.xml）。此端点的源文件位于与环境端点相同的方式：与属性或YAML文件相同的搜索路径，而不是聚合所有匹配的资源，只返回匹配的第一个。
找到资源后，使用正确格式（${…}）的占位符将使用有效的Environment解析为应用程序名称，配置文件和标签提供。以这种方式，资源端点与环境端点紧密集成。例如，如果您有一个GIT（或SVN）资源库的布局：
application.yml
nginx.conf
其中nginx.conf如下所示：
server {
listen 80;
server_name ${nginx.server.name};
}
和application.yml这样：
nginx:
server:
name: example.com
---
spring:
profiles: development
nginx:
server:
name: develop.com
那么/foo/default/master/nginx.conf资源如下所示：
server {
listen 80;
server_name example.com;
}
和/foo/development/master/nginx.conf这样：
server {
listen 80;
server_name develop.com;
}
注意就像环境配置的源文件一样，“配置文件”用于解析文件名，因此，如果您想要一个特定于配置文件的文件，则logback.xml将由一个名为logback-development.xml的文件解析（优先于logback.xml）。
网友评论