Laravel-json-api: Translate some Exceptions into a JSON:API error response

[tembra]

Hello @lindyhopchris

How would you translate a Laravel QueryException into a JSON:API error response?

I know that we must use Exceptions\Handler.php for this, but how would you code this?

Currently the API is just responding with a 500 Internal Server Error. I would like to translate some SQL errors like [23503] violates foreign key constraint to let the user known what to do instead of simple get an internal server error.

I know that I can simple create a new Error object an return it JSON:API encoded. However do you have/use json_api()->response()->exception($e); and I want to know if I can make some use of it for my use case.

Thank you.

[lindyhopchris]

So I'd question why you're letting invalid data hit the database... the convention here would be to use validation rules to reject the data before it is attempted to be inserted. I.e. for foreign key constraints, your validation should pick up on this and reject the request at the validation point - then you can use validation messages to provide the correct information to the client.

A 500 Internal Server Error is the correct response for a QueryException.

Can you not use rules e.g. exists for your scenario?

[jstoone]

@tembra are you by any chance talking from the context of your tests, or are you planning on letting the framework exception render to the consumers of your API? Which as Chris also points out above, might not be the best idea.

The reason why I'm asking this, is that my colleague had a similar problem where if one of his tests would fail, it would only return the default JSON:API 500 status code response, which ofc. is not optimal when you are debugging on your local environment.

Luckily it was only a matter of a misconfiguraion in the Exceptions\Handler-class, as you also point out, which I'll gladly help you out with fixing. :v:

Just wanted to make sure in which context you're asking this question since, hypothetically, you might assume an implied context of "testing" for the given question, whereas another reader might assume a totally different context, which can lead to some VERY interresting conversations. :smile:

[lindyhopchris]

Ah yeah, a good tip for testing is if you don't expect your test to cause an exception, then using the withoutExceptionHandling() method before submitting the test request means you'll see the actual exception.

[lindyhopchris]

The testing story might get a bit easier when I get to 2.0 because the plan is not to use the annoying JsonApiException class that the neomerx/json-api package throws.

[tembra]

@jstoone I'm not talking about tests. It's about to deliver a message for the consumers of API. But I got your point. Thx.

@lindyhopchris Understood and totally agree with you. I was thinking to use exception handler to translate this type of error because we may have a lot of resource where the front end must first delete the related resources before delete the main resource. However the best way to lead with this is to follow the convention you told: use rules to reject the request before it's process. BTW I can not use validation rules because it's on DELETE endpoint.

Finally I was right to post the question here to get your and the community's opinion on how to handle this case 😄

Thanks once.

PS: We use these foreign keys as restrict mode on purpose in our database.

[lindyhopchris]

Actually this package does support delete validation, here's the link to it in the docs:
https://laravel-json-api.readthedocs.io/en/latest/basics/validators/#delete-resource-validation

Going to close this issue as I don't think there's anything for me to change in the package, but let me know if you disagree!