Support "href" in resource identifier objects

[ethanresnick]

It is sometimes useful for a resource identifier object that points to a resource that isn't included in the document to contain the URI of that resource. That way, the client can request it without having to ask for the whole "related" collection, and without the server needing to support the related endpoint.

This need has come up repeatedly on the discourse forum, and is also the issue in #477.

Here, I'm suggesting we address this use case by adding an "href" key to resource identifier objects. I prefer this approach over, say, adding a "links" key to resource identifier objects, because it stresses the conceptual similarity between link and resource identifier objects (without going as far as I propose in #913). By contrast, adding a "links" key would suggest a similarity between resource objects and resource identifier objects, which are conceptually very distinct and are (if anything) already too easy to confuse.

[ethanresnick]

Actually, let's hold off on merging this... I want to think more about whether it's appropriate. Because, while it's true that resource identifier objects point to a target of a particular link relation (and in that sense are very much like link objects), they also have a dual nature of being primary data (and so being paginatable etc.). Therefore, maybe a "links" key in them (with a "related" link??) is appropriate? Alternatively, we could still see resource identifier objects as conceptually a type of link object, if we just say that link objects can occur as primary data (in relationship endpoints...).

Thoughts?

[dgeb]

Hmmm ... I agree that we need to pause and carefully consider whether links or href is more appropriate for resource identifier objects. Everywhere that we allow links we allow a self member, and yet the spec doesn't have the concept of allowing direct access to an identifier object (nor do I see value in allowing that). I suppose we could allow links and not self. As for href - I find it to be a bit inconsistent with the rest of the spec.

[jelhan]

By contrast, adding a "links" key would suggest a similarity between resource objects and resource identifier objects, which are conceptually very distinct and are (if anything) already too easy to confuse.

Why do you see them as conceptually very different. I thought of resource identifier objects as a subset of resource objects. To even stress it more: I don't see how a resource object without any field and without meta is distinct from a resource identifier object. At the end of the day it would be the same JSON.

Treating resource identifier objects as a subset of resource objects would simplify this question a lot. The links.self in a resource object could be the same as for the corresponding resource identifier object.

As dgeb pointed out, having dedicated self link for a resource identifier object does not seem to provide any value. But even if we want that, we could add a dedicated member to links of a resource object and resource identifier object for it. We could name it links.identifier for example.

[jelhan]

I'm going to close this. The PR is stale for a couple of years now. @ethanresnick and @dgeb shared in their last comments that they aren't convinced that it is the right direction.