laravel-json-api: Attach meta to error objects

Hi,

First of all, thanks for your work on this awesome project…

I’m current;y investigating the possibility of adding meta information to the attributes validation errors returned when creating/updating resources (as per JSON-API v1.0 specs, https://jsonapi.org/format/#error-objects).

My use case would be to add a machine-readable description of each validation error, to complement the human-readable one found under “details”… Something like :

{
    "status": "422",
    "title": "Unprocessable Entity",
    "detail": "The status must be between 1 and 5.",
    "source": {
        "pointer": "/data/attributes/status"
    },
    "meta": {
        "machine_description": {
            "between": [
                "1",
                "5"
            ]
        }
    }
}

With Laravel, calling $validator->failed() returns a pretty decent (when JSON-encoded) machine-readable description of all errors, for example, given the following rules :

[
 'title' => 'bail|required|string|min:5|max:10',
 'pages' => 'bail|required|numeric',
 'body' => 'required|string|same:title|not_in:foo,bar',
 'else' => 'required',
 'comments' => 'bail|min:3',
 'comments.*.author' => 'bail|required|string',
]

and the following attributes :

{
	"title": "foo",
	"pages": "a",
	"body": "foo",
	"else": "test"
}

$validator->failed() would return something like this :

{
    "title": {
        "min": [
            "5"
        ]
    },
    "pages": {
        "numeric": []
    },
    "body": {
        "notin": [
            "foo",
            "bar"
        ]
    }
}

Anyway… the actual use of this feature is not important here, my question is simply : it is currently possible to add meta info to error objects? If not, where should I begin to investigate in order to achieve such a thing?

Maybe a new method (getMeta) could be added to the AbtractValidators class, which would access the validator instance and the error path (source/pointer), the return value being added as meta to the error?

Thanks for your help…

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 20 (10 by maintainers)

Most upvoted comments

So my plan is to santise the database ones and also to run the rule name through the translator so that it can be translated if desired. That means that someone could add translations for FQNs of rule objects.

Hoping to get this done sometime next week - been on frontend stuff this week so not been able to sort this out yet.

lindyhopchris on Jan 25, 2019

@gendronb

I’ve just pushed a issue263 branch with a single commit that adds in the failed meta to each error object - so you can see on that how it’s wired in. The main thing is the ErrorTranslator is where the error object is created. Although not yet documented, overriding the ErrorTranslator in the service container is how I’d intend an application to customise the errors that are created. The other changes on the commit are about ensuring that the error translator is given the failed information in addition to the validation key and detail.

The order of the messages and failed data works in Laravel 5.5, 5.6 and 5.7. It does feel a little unsafe but I think this is a fantastic feature so I’m inclined to add it for 1.0.0 as an opt-in feature. (I’d have to add some code as to how to opt in to it.)

Would be good if you could have a play with the issue263 branch in your application and let me know how you get on. If it meets your requirements, I’ll add the opt-in code then merge.

lindyhopchris on Jan 11, 2019

Ah ok I’d misunderstood! I’ll take a look as to how you could implement this. Actually we have a production API where it would be really useful to include this information, so I can definitely see the benefit of supporting this.

lindyhopchris on Dec 1, 2018

Good point. I think it should potentially be the default because if Laravel does it by default in the JSON for validation messages, then this package should replicate what Laravel does in JSON but in the JSON API format.

Definitely needs more research. In terms of overriding the implementation, but the current class that is generating the errors from the validations isn’t given access to the data that you’d need. I’ll have to look into this in a bit more detail to see how it could be implemented.

lindyhopchris on Nov 30, 2018

Ah I did not realise Laravel returned that information in the JSON. I think it would be good for this package to automatically add that data to the error meta. So I’ll add this to the feature list but it’ll probably not land until the after the 1.0.0 release.

lindyhopchris on Nov 30, 2018