Improve the structure of the response from the /env endpoint

[wilkinsona]

Property sources in the environment are ordered, however the /env endpoint doesn't guarantee that a client will see this ordering. It uses a map for the property sources and, while the entries are ordered on the server side, there's no guarantee that a client will preserve that ordering. For example, the ordering of the keys with curl is:

• profiles
• server.ports
• servletContextInitParams
• systemProperties
• systemEnvironment
• applicationConfig: [classpath:/application.properties]

But the ordering of the keys with HTTPie is alphabetical:

• applicationConfig: [classpath:/application.properties]
• profiles
• server.ports
• servletContextInitParams
• systemEnvironment
• systemProperties

There's also a secondary problem that profiles isn't a property source (it's actually a list of the environment's active profiles) and if someone adds a property source named profiles the two will clash and the profiles property source will overwrite the list of the environment's active profiles.

To make it clear that the ordering of the property sources is significant I think it would be better if the response used a list rather than a map. This would also separate the property sources from the list of active profiles, avoiding the clash. Something like this:

{
    "activeProfiles": [],
    "propertySources": [
        {
            "name": "systemEnvironment",
            "properties": {
                // …
            }
        },
        {
            "name": "systemProperties",
            "properties": {
                // …
            }
        }
    ]
}

[spencergibb]

That's very similar to the format returned from config server

[philwebb]

We should also add the property origin information now that we have it.

[wilkinsona]

To include the origin information, properties could become an array of property objects:

"properties": [
    {
        "name": "foo",
        "value": "one",
        "origin":"…"
    },
    {
        "name": "bar",
        "value": "two",
        "origin":"…"
    }
]

Alternatively, it could continue to be an object with the keys being the property names:

"properties": {
    "foo": {
        "value": "one",
        "origin": "…"
    },
    "bar": {
        "value": "two",
        "origin": "…"
    }
]

I have a slight preference for the latter as it reinforces the fact that property names are unique within a given source. Ordering isn't important so there's nothing to be gained by using an array.