Api: Should work out of box with Laravel 5 / Lumen controller validate method

Created on 25 Mar 2016  路  3Comments  路  Source: dingo/api

Laravel 5 and Lumen both provide a convenience method on the controller for validation, so you can easily do:

$this->validate($request, $rules);

and it will handle creating the validator, checking the rules, and throwing an exception. The problem is this gets caught and transformed into a 500 error - so the developer is left implementing a custom method on the controller to handle this (see #584).

Per my comment on that issue, it's a fairly easy override. In the controller you can simply use:

use Dingo\Api\Exception\ValidationHttpException;

class ApiController extends BaseController {
  protected function throwValidationException(\Illuminate\Http\Request $request, $validator) {
    throw new ValidationHttpException($validator->errors());
  }
}

Isn't this something that should be included out-of-the-box with Dingo? I've been surprised to find out that I have to create exception handlers manually for several typical scenarios:

  1. Using standard Lumen authorization (AuthServiceProvider with Gate and Policies) I had to manually catch Illuminate\Auth\Access\AuthorizationException and throw Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException
  2. Using standard Eloquent models, for findOrFail($id) I had to manually catch Illuminate\Database\Eloquent\ModelNotFoundException and throw Symfony\Component\HttpKernel\Exception\NotFoundHttpException
  3. And for the validator, if I want to use the convenience method provided by Lumen instead of instantiating a validator myself, I have to override the throwValidationException method to include the validation errors in the exception.

Most helpful comment

I'm sorry to comment on a issue which has already been closed but I thought @jdforsythe had made a very good point of the missing puzzle. Laravel/Lumen throw their own exceptions cause they have owned handlers themselves, but dingo, as a not a very framework independent package has it's responsibility to wrap them up to forming a complete API layer abstraction.

A "Custom API Error Handler Support" would resolve @jasonlewis 's concern by the way.

All 3 comments

I'm not so sure on bootstrapping all the things. I know that's how _you_ would like to handle it, but what about John Doe who wants to handle it differently, and Mary Jane who also handles it differently to John and you.

I suppose there could be room for some sort of bootstrapped variant that has everything you'd need to configure already done. But I'd prefer to keep it as simple as possible. I'm honestly not impressed with what it's doing at the moment. Becoming way to convoluted.

I'm sorry to comment on a issue which has already been closed but I thought @jdforsythe had made a very good point of the missing puzzle. Laravel/Lumen throw their own exceptions cause they have owned handlers themselves, but dingo, as a not a very framework independent package has it's responsibility to wrap them up to forming a complete API layer abstraction.

A "Custom API Error Handler Support" would resolve @jasonlewis 's concern by the way.

@jasonlewis I agree with @18601673727 . If this was a very framework independent package that would be one thing. But it's not. Also your concern about how some people would want it different is resolved by @18601673727 comment anyway.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

pongz79 picture pongz79  路  4Comments

pedrolari picture pedrolari  路  3Comments

tankhit picture tankhit  路  3Comments

sukh-gill picture sukh-gill  路  3Comments

BartHuis picture BartHuis  路  3Comments