Skip to content

Example Error Objects #828

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

Merged
merged 4 commits into from
Aug 26, 2015
Merged

Example Error Objects #828

merged 4 commits into from
Aug 26, 2015

Conversation

bf4
Copy link
Contributor

@bf4 bf4 commented Aug 5, 2015

Per discussion with @dgeb in rails-api/active_model_serializers#1004

Although it is still compliant to represent multiple validation errors in the same error object,
it's not ideal. I would recommend creating a unique error object per validation error,
so that fields such as code and title can be used consistently and expressively across errors.
For instance, one code might indicate that a field is too short, and another might indicate
that invalid characters were used. If you try to combine these errors into a single code,
then it will probably end up being something more generic with less meaning, such as "invalid value".

References:

{
"errors": [
{
"source": { "pointer": "data/attributes/first_name" },
Copy link
Member

Choose a reason for hiding this comment

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

Although underscores are compliant, I'd prefer to use dasherized names, such as first-name, in examples as per our recommendations.

@steveklabnik
Copy link
Contributor

Thanks for this! Good examples are so crucial to getting a spec adopted.

"detail": "is too short"
},
{
"status": "422",
Copy link
Member

Choose a reason for hiding this comment

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

Having status in isolation seems a bit odd. In this example, I'd expect it to be part of the first error object.

I think an example that shows multiple different errors with different status values would be great. For example, one error object could be a 404 and another 422, and the status for the whole response could be 400.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great, thanks! I made it this way on purpose since I didn't understand when error objects might have different status attributes.

@dgeb
Copy link
Member

dgeb commented Aug 5, 2015

Thanks for this! Good examples are so crucial to getting a spec adopted.

Agreed! Great start here, @bf4 👍

@bf4
Copy link
Contributor Author

bf4 commented Aug 6, 2015

I've made some updates, there might be some code blindness going on here.. I'm not sure if I did 'parameter' right. It appears to have evolved from 'path'.

I'm also thinking about adding examples of an error object with

  • a links object
  • a meta object
  • a source pointer to a 'primary' data object.

And a response with, in addition to an errors top-level member, the other valid top-level members

  • meta: a meta object that contains non-standard meta-information.
  • jsonapi: an object describing the server's implementation
  • links: a links object related to the primary data. (?)

@bf4
Copy link
Contributor Author

bf4 commented Aug 11, 2015

@dgeb @steveklabnik Any more feedback on the changes? (I've made them in incremental commits)

{
"errors": [
{
"id": "ds.errors.invalid-error-expects-json-api-format",
Copy link
Member

Choose a reason for hiding this comment

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

This looks more like a code than an id:

id: a unique identifier for this particular occurrence of the problem.
code: an application-specific error code, expressed as a string value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, looks like I somehow mixed up code and id here and in the error codes section as well

FWIW, I got it from https://github.com/emberjs/data/blob/d842890357840700f0ee17f152415be0cba16030/packages/ember-data/lib/adapters/errors.js#L82

    Ember.deprecate('`InvalidError` expects json-api formatted errors.', false, { id: 'ds.errors.invalid-error-expects-json-api-format', until: '2.0.0' });

which I misread as an errors object

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

```

```http
HTTP/1.1 404 Not Found
Copy link
Member

Choose a reason for hiding this comment

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

Should be 400, since errors include 404 and 403 statuses.

"source": { "pointer": "data/relationships/author" },
"detail": "Post author cannot be blank."
}
]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bf4
Copy link
Contributor Author

bf4 commented Aug 12, 2015

@dgeb updated and rebased and added a few more source examples. What would a meta example be in an error object (not top-level member meta)?

@bf4
Copy link
Contributor Author

bf4 commented Aug 17, 2015

New and improved ✨

{
"title": "Adapter Error",
"code": "ds.errors.invalid-error-expects-json-api-format",
"detail": "The adapter rejected the commit because it was invalid"
Copy link
Member

Choose a reason for hiding this comment

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

Can you make the detail message here a bit more distinct than the title than it is now?

Also, can you add status to one of the earlier examples, in addition to having it on the one below? I don't want to imply through the examples that status is only applicable in cases where there are multiple errors returned at once. It can be useful too when the code processing the JSON isn't directly aware of the HTTP response (and could be useful also if JSON API is eventually used over non-HTTP protocols).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure. FWIW, I got that example title/code/detail off of the ember-data project :).

},
{
"code": "225",
"source": { "pointer": "data/attributes/password" },
Copy link
Member

Choose a reason for hiding this comment

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

Ditto

@ethanresnick
Copy link
Member

@bf4 Thanks for all your hard work! This looks great to me now.

Please fix the small errors with the JSON Pointers, and then I think this is good to merge, unless @dgeb or @tkellen want to review it first.

@bf4
Copy link
Contributor Author

bf4 commented Aug 23, 2015

Merge commit amended and force-pushed.

}
```

It uses `source` to point to the top-level of the document (`"/"`).
Copy link
Member

Choose a reason for hiding this comment

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

This line needs to say "" instead of the old "/".

Also, I think my comment about why "/" is inappropriate got accidentally merged into the response. It doesn't make sense there, though, because my example document with {"": "some value"} is missing, and because a server isn't allowed to respond with comments in its JSON. If you want to explain why "" is used rather than "/", please do it in this paragraph instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

you a copy editor or I'm just tired of re-reading this ? :)

Copy link
Member

Choose a reason for hiding this comment

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

Maybe both :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added an incremental commit to address this to aid in future reviewing. I'll rebase into the merge commit once we're happy.

@ethanresnick
Copy link
Member

👍

@bf4
Copy link
Contributor Author

bf4 commented Aug 23, 2015

fixing merge conflict... hold on

@bf4
Copy link
Contributor Author

bf4 commented Aug 23, 2015

rebased

@bf4
Copy link
Contributor Author

bf4 commented Aug 26, 2015

@ethanresnick LGTM?

@ethanresnick
Copy link
Member

LGTM. Merged.

ethanresnick added a commit that referenced this pull request Aug 26, 2015
@ethanresnick ethanresnick merged commit 13e0f00 into json-api:gh-pages Aug 26, 2015
ethanresnick added a commit to ethanresnick/json-api-1 that referenced this pull request Aug 26, 2015
Another small complement to json-api#863, to accommodate the table in json-api#828
@bf4
Copy link
Contributor Author

bf4 commented Aug 26, 2015

omg omg 🎆 🌈 ❗ 💥 👯 ❤️ 😍 😃 💯

@bf4 bf4 deleted the errors_example branch August 26, 2015 19:31
@joaomdmoura
Copy link

🎉 🎉 🎉 🎉 🎉

@dgeb
Copy link
Member

dgeb commented Aug 26, 2015

Really pleased to see this merged. We've needed some error examples for months.

@bf4 thanks for all your work here! 💯

@ethanresnick thanks for finishing the review! 🎉

benoittgt pushed a commit to benoittgt/json-api that referenced this pull request Aug 27, 2015
Another small complement to json-api#863, to accommodate the table in json-api#828
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
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