Skip to content

The members data and errors MUST NOT coexist in the same document. #45

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
Open
Unisay opened this issue May 12, 2016 · 5 comments
Open

The members data and errors MUST NOT coexist in the same document. #45

Unisay opened this issue May 12, 2016 · 5 comments
Labels
duplicate

Comments

@Unisay
Copy link
Contributor

Unisay commented May 12, 2016 •
edited
Loading

At the moment, RootObject is

  case class RootObject(
    data: Option[RootObject.Data] = None,
    links: Option[Links] = None,
    errors: Option[Errors] = None,
    meta: Option[Meta] = None,
    included: Option[Included] = None,
    jsonApi: Option[JsonApi] = None)

thus making it possible to instantiate a RootObject with both data and errors.

However, JSON-API spec clearly says:
http://jsonapi.org/format/#document-top-level

The members data and errors MUST NOT coexist in the same document.

Suggestion:

  case class RootObject(
    body: Either[Errors, RootObject.Data], // <<<< 
    links: Option[Links] = None,
    meta: Option[Meta] = None,
    included: Option[Included] = None,
    jsonApi: Option[JsonApi] = None)

(but it makes it impossible to have neither data nor errors)
@asgoncalves
Copy link
Contributor

we are aware of this problem.
see issue #6

@lasomethingsomething
Copy link

Hey @asgoncalves, can we close this issue? It dates back to May 2016.

@oporkka
Copy link
Collaborator

oporkka commented Feb 7, 2017 •
edited
Loading

In my opinion this should stay open since the code has not been yet fixed and this is only a sub-issue of #6 which in turn is too broad. I'd divide it to sub-issues like this or otherwise it'll become a dinosaur that we'll never fix.

@lasomethingsomething
Copy link

@oporkka Yes, splitting things into smaller to-do's is a great idea. How would you like to go about it?

@oporkka
Copy link
Collaborator

oporkka commented Feb 8, 2017

My proposal is to keep #6 open as an epic and gather the smaller issues under it. We can edit the description there and list the sub-issues there. It would be great if someone who knows could list what parts of the spec are actually missing. However we can also list the smaller issues there as they come up based on people's needs and observations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
duplicate
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@zmeda @oporkka @Unisay @lasomethingsomething @asgoncalves