On the ExceptionHandler the render should check for if it's a Ajax request. about laravel-api-response-builder HOT 3 CLOSED

This is intentional and by design API must always return standardized JSON response, no matter what happened. That is the purpose of that ErrorHandler - to ensure this works that way, co slient app is not confused. There's no single benefit from breaking that rule. All it would make is whole things much worse to deal with. While you can easily alter the version you use I strongly suggest not doing so. This is just wrong.

from laravel-api-response-builder.

@MarcinOrlowski so your saying I need to split my api up & not have a site & api on the same install? It's still not user friendly for a customer to see a 404 json response when they're browsing the site? They should see a 404 blade view response.

from laravel-api-response-builder.

I am saying that your API should ALWAYS return JSON. This is what clients (programs, not humans!) consuming your API expect. There's absolutely no reason to return HTML from API. HTML error code 404 is also no exception from that. My ExceptionHandler will return standarized JSON, with success being false and closer details in message. This is perfectly sufficient for automated handling. Joe User does not need to be able to deal with it anyway as no user needs to call you API by hand and if s/he does so w/o knowledge what s/he is doing, then I'd just say it his problem.

And yes, separating API from main is a good thing. If both codes (API and website) share some code (i.e. models) you may create 3rd package with these elements and have them included in both projects via composer. Alternatively you need to modify the code to better handle 404, i.e. if request is for api/foo/bar and bar does not exists, then you need tor return JSON as this is api path, but if you face pages/bar and bar is non existing, then you need to return HTML 404. Lot of pointless work. Do the separation.

from laravel-api-response-builder.