Open JoeWoodward opened 6 years ago
Should we override the error description if the pointer is missing? http://jsonapi.org/examples/#error-objects-source-usage the example here returns a description
"detail": "Missing data Member at document's top level." which maybe makes more sense. Then supply the original error in the meta
i.e.
{
"errors": [
{
"detail": "Missing `name` Member at document's /data/attributes level",
"source": {
"pointer": "/data/attributes"
},
"meta": {
"detailed_error_message": {
"title": "Invalid name",
"detail": "Name cannot be blank"
}
}
}
],
"jsonapi": {
"version": "1.0"
}
}
Maybe the meta is overkill. Probably enough to just override the detail and remote the title
IIRC, the /data
pointer should always be valid, unless the payload itself is invalid (to be double checked), in which case we could add some logic to craft the right pointer/error depending on the payload (/data
vs /data/attributes
).
I think that's the issue though. The following is a valid payload
{
data: {
attributes: {}
}
}
Even if the logic was changed to consider this invalid we can still get null pointers with missing attributes. e.g.
{
data: {
type: 'users',
attributes: {
email: 'valid@mail.com'
# name: 'expected but not passed at all, not just null'
}
}
}
{
"errors": [
{
"title": "Invalid name",
"detail": "Name can't be blank",
"source": {}
}
],
"jsonapi": {
"version": "1.0"
}
}
There is an issue with this PR though; The error isn't necessarily going to be from a member on /data/attributes
. I actually looked back at this repo because I was researching sideposting, which I believe isn't through the attributes node so returning source: { pointer: '/data/attributes' }
would be invalid.
Maybe there's a way to decipher the pointer from the AM::Errors hash. Need to look into it further
This PR fixes the source pointer when the payload is missing a validated attribute.
e.g.
if we post
We get back an error with an empty pointer
With this change we return the node where the attribute is missing from