Skip to content

Relationships object #625

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 7 commits into from
Closed

Relationships object #625

wants to merge 7 commits into from

Conversation

ethanresnick
Copy link
Member

A PR for #618. See the inline comments for some new issues that arose while I was creating it.

@ethanresnick
Initial definition of resource-level "relationships" object separat…
497c186 
…e from resource `"links"`
@ethanresnick
Fix broken link to attributes object
d22d5c8
@ethanresnick
Rework Top-Level Links section
88306e9 
Now that we have a consistent `links` format everywhere, which is
always optional, this object seemed analogous to the `meta` object, so
I restructured its section to better match the structure of the “Meta
Information” section.
@ethanresnick
Update recommendations to account for relationships object
b7e7ab9
ethanresnick
ethanresnick reviewed May 17, 2015
View reviewed changes
format/index.md
The name of the relationship declared in the key **SHALL NOT** be `"self"`.
Relationships may be to-one or to-many. Relationships can be specified by
including a member in a resource's relationship's object. The name of the
relationship is its key in the the relationship object.

The value of a relationship **MUST** be one of the following:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dgeb @tkellen How would you guys feel now about getting rid of the "name": "related resource url" representation of a relationship? There was an argument for removing it before, and I think that argument's much stronger now, as this would be the only instance in the spec of a URL occuring outside of a "links" object.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ethanresnick I agree that representation should be removed from this proposal, since it no longer merges the concept of links and relationships.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@ethanresnick ethanresnick force-pushed the relationships-object branch from b7aefca to d781618 Compare May 17, 2015 18:29
@dgeb
Copy link
Member

dgeb commented May 17, 2015

@ethanresnick thanks for all your hard work on this! @tkellen and I will review and discuss first thing tomorrow.

@ethanresnick
Copy link
Member Author

@dgeb Sounds good!

@tkellen
Copy link
Member

tkellen commented May 18, 2015

Late night 👍 on this. Excited to take a more considered look tomorrow AM. Thanks for proposing this @ethanresnick!

@ethanresnick
Copy link
Member Author

Thanks for the proofreading, @hhware! Much appreciated!

@ethanresnick ethanresnick force-pushed the relationships-object branch from 9b9e6db to cecf671 Compare May 18, 2015 07:42
@dgeb
Copy link
Member

dgeb commented May 18, 2015

@ethanresnick at this point, @tkellen and I think that data makes more sense than linkage in a relationship object. This could be termed "relationship data" and would of course be accessible at "relationship URLs". What do you think?

@dgeb
Copy link
Member

dgeb commented May 18, 2015

To expand on that thought - it establishes data as the generic key to represent the data behind any kind of custom element - such as a relationship object. When elements, such as relationship objects, are retrieved at their self links, their data will be accessible as the top-level data member. I think it's a simplifying move that provides a good convention for future extension.

@ethanresnick
Copy link
Member Author

@dgeb Yup! I really like that! Should I add it to this PR, or should we merge this and open a second one?

EDIT: I've gotta run an errand now, but I'll put together PRs tonight for all the issues you and @tkellen +1d

@dgeb
Copy link
Member

dgeb commented May 18, 2015

@ethanresnick sounds great - thanks in advance!

@hhware hhware mentioned this pull request May 18, 2015
Closed
@dgeb
Copy link
Member

dgeb commented May 19, 2015

@ethanresnick I'm going to rebase and merge this along with the data change I mentioned above.

@dgeb
Copy link
Member

dgeb commented May 19, 2015

Rebased and merged (see https://github.com/json-api/json-api/commits/gh-pages). I'll open a separate PR for the linkage -> data change mentioned above.

@dgeb dgeb closed this May 19, 2015
@dgeb dgeb mentioned this pull request May 19, 2015
Closed
@ethanresnick
Copy link
Member Author

Thanks @dgeb! Sounds good, and sorry I wasn't able to open that last night.

@tkellen
Copy link
Member

tkellen commented May 19, 2015

I'll have a PR in shortly with some minor revisions for cleanup/clarity and then I'm out for the day.

@dgeb dgeb mentioned this pull request May 20, 2015
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@ethanresnick @dgeb @tkellen @hhware
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy