New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support `"href"` in resource identifier objects #926

Open
wants to merge 1 commit into
base: gh-pages
from

Conversation

Projects
None yet
2 participants
@ethanresnick
Copy link
Member

ethanresnick commented Nov 29, 2015

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 ethanresnick force-pushed the ethanresnick:href-in-resource-identifiers branch from 1b08b28 to 34286d8 Nov 29, 2015

@ethanresnick

This comment has been minimized.

Copy link
Member Author

ethanresnick commented Nov 29, 2015

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

This comment has been minimized.

Copy link
Member

dgeb commented Nov 29, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment