identity-doc response format not consistent in token response and other responses

[Haneef Ali]

In token, the entity's domain is embeded as an object. But if you do a GET on the entitty, then domain object is not embdded. Why do we have 2 different response?

e.g
Project from token response

 "project": {
            "domain": {
                "id": "1789d1",
                "links": {
                    "self": "http://identity:35357/v3/domains/1789d1"
                },
                "name": "example.com"
            },
            "id": "263fd9",
            "links": {
                "self": "http://identity:35357/v3/projects/263fd9"
            },
            "name": "project-x"
        },

GET Projects response

{
    "domain_id": "--domain-id--",
    "enabled": true,
    "id": "--project-id--",
    "link": {
        "href": "http://identity:35357/v3/projects/--project-id--",
        "rel": "self"
    },
    "name": "a project name"
}

[Dolph Mathews (dolph)]

For better or worse, I'll take credit for this decision.

The format used by /v3/auth is actually preferred, as it's a bit more forward-looking. The primary benefit is that links can be provided on nested objects along with various identification methods in requests (which follow the same syntax differences as the responses shown here), such as ID, link, name w/ parent reference, etc.

Given that we'll have to support /v3/auth longer than the rest of the API, I think it makes sense to make an exception there, and support the flattened attributes (e.g. entity_id) on the rest of the API as a backwards compatibility as we move toward supporting nested objects on the rest of the API.