Let _embedded reference other items from the representation.

[spaceone]

It would be nice if embedded resources could point to a location inside the current representation where the data lie.

Example:

instead of:

{
    "results": 2,
    "_embedded": {
        "foo:objects": {
            {"foo": "bar", "_links": {}},
            {"bar": "baz", "_links": {}},
        }  
    },
    "_links": {
        "curies": {
            "name": "foo",
            "href": "bar"
        }
    }
}

I would like to write:

{
    "results": 2,
    "objects": [
        {"foo": "bar", "_links": {}},
        {"bar": "baz", "_links": {}},
    ],
    "_embedded": {
        "foo:objects": $LINK_TO('/objects')$
    },
    "_links": {
        "curies": {
            "name": "foo",
            "href": "bar"
        }
    }
}

where $LINK_TO('/objects')$ should be some non-breaking idea. Maybe something like:

"_links": {
    "hal:embedded-ref": "/objects"
}

which would be a xpath / jsonpath expression.
:-( this would be a dependency on another library.
TODO / RFC: find a better idea

For me it would be enough to reference a top-level item.

• This would allow to define arbitrary JSON structures which are also compatible with e.g. an OpenAPI schema.
• This would flatten the structure of the document for e.g. readability (and non HAL consumers)
• This would allow to take a response payload and PUT it back as application/json without the need to transform it (just maybe dropping _links and _embedded).
• Tradeoff: This adds more logic to HAL clients and maybe a dependency on a xpath/jsonpath library
• This would separate contents from metadata. I interpret hypertext as the engine of application state in the way that the hypertext is just descriptive additional metadata not necessarily part of the response structure (well OK, in a HTML document you have the <form> somewhere mixed in the content).
• It would also ease the transition to HAL for existing applications as they only need to add _links + _embedded without transforming the prior content and therefor allow easier backwards compatibility (except for Content-Type: application/hal+json)