【问题标题】:How to force FormRequest return json in Laravel 5.1?如何在 Laravel 5.1 中强制 FormRequest 返回 json?
【发布时间】:2015-10-09 01:33:58
【问题描述】:

我正在使用FormRequest 来验证从我的智能手机应用程序的 API 调用中发送的内容。所以,我希望 FormRequest 在验证失败时总是返回 json。

看到下面Laravel框架的源码,FormRequest的默认行为是reqeust是ajax或者wantJson返回json。

//Illuminate\Foundation\Http\FormRequest class
/**
 * Get the proper failed validation response for the request.
 *
 * @param  array  $errors
 * @return \Symfony\Component\HttpFoundation\Response
 */
public function response(array $errors)
{
    if ($this->ajax() || $this->wantsJson()) {
        return new JsonResponse($errors, 422);
    }

    return $this->redirector->to($this->getRedirectUrl())
                                    ->withInput($this->except($this->dontFlash))
                                    ->withErrors($errors, $this->errorBag);
}

我知道我可以在请求标头中添加Accept= application/json。 FormRequest 将返回 json。但我想提供一种更简单的方法来通过默认支持 json 来请求我的 API,而无需设置任何标头。所以,我试图在Illuminate\Foundation\Http\FormRequest 类中找到一些强制FormRequest 响应json 的选项。但我没有找到默认支持的任何选项。

解决方案 1:覆盖请求抽象类

我试图覆盖我的应用程序请求抽象类,如下所示:

<?php

namespace Laravel5Cg\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\JsonResponse;

abstract class Request extends FormRequest
{
    /**
     * Force response json type when validation fails
     * @var bool
     */
    protected $forceJsonResponse = false;

    /**
     * Get the proper failed validation response for the request.
     *
     * @param  array  $errors
     * @return \Symfony\Component\HttpFoundation\Response
     */
    public function response(array $errors)
    {
        if ($this->forceJsonResponse || $this->ajax() || $this->wantsJson()) {
            return new JsonResponse($errors, 422);
        }

        return $this->redirector->to($this->getRedirectUrl())
            ->withInput($this->except($this->dontFlash))
            ->withErrors($errors, $this->errorBag);
    }
}

如果我们需要强制响应json,我添加了protected $forceJsonResponse = false;。并且,在每个从 Request 抽象类扩展的 FormRequest 中。我设置了那个选项。

例如:我创建了一个 StoreBlogPostRequest 并为此 FormRequest 设置 $forceJsoResponse=true 并使其响应 json。

<?php

namespace Laravel5Cg\Http\Requests;

use Laravel5Cg\Http\Requests\Request;

class StoreBlogPostRequest extends Request
{

    /**
     * Force response json type when validation fails
     * @var bool
     */

     protected $forceJsonResponse = true;
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'title' => 'required|unique:posts|max:255',
            'body' => 'required',
        ];
    }
}

解决方案2:添加中间件并强制更改请求标头

我构建了一个中间件,如下所示:

namespace Laravel5Cg\Http\Middleware;

use Closure;
use Symfony\Component\HttpFoundation\HeaderBag;

class AddJsonAcceptHeader
{
    /**
     * Add Json HTTP_ACCEPT header for an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $request->server->set('HTTP_ACCEPT', 'application/json');
        $request->headers = new HeaderBag($request->server->getHeaders());
        return $next($request);
    }
}

这是工作。但我想知道这个解决方案好吗?在这种情况下有什么 Laravel 方法可以帮助我吗?

【问题讨论】:

  • 您好,只是一个建议,既然您要求默认响应类型,那么为什么不通过在您的句柄方法$request-&gt;header('accept', 'application/json'); return $next($request); 中添加一个中间件并将请求类型添加到 json 中,您有一个进行进一步扩展的地方,而不总是覆盖任何方法
  • 谢谢!这是个好主意。我想。我会在上面的问题中更新这个实现
  • 对不起。我试图设置 $request->header('Accept','application/json');在中间件中,但我发现我的请求具有默认的 Accept 标头“/”,因此我无法覆盖该 Accept 标头。我没有在请求中设置任何内容。
  • 没关系,是否在标头中设置了默认接受值,中间件值将覆盖它$request = $request-&gt;header('Accept','application/json'); return $next($request); 我认为,请求没有被持久化。
  • 我找到了覆盖请求头的方法,我们需要设置 $request->server 并重建 headerBag 如下: $request->server->set('HTTP_ACCEPT', 'application/json' ); $request->headers = new HeaderBag($request->server->getHeaders());

标签: php laravel laravel-5 laravel-validation


【解决方案1】:

基于ZeroOne's response,如果您正在使用Form Request validation,您可以覆盖 failedValidation 方法以在验证失败时始终返回 json。

这个解决方案的好处是,您不会覆盖所有返回 json 的响应,而只是验证失败。因此,对于所有其他 Php 异常,您仍然会看到友好的 Laravel 错误页面。

namespace App\Http\Requests;

use Illuminate\Contracts\Validation\Validator;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\Exceptions\HttpResponseException;
use Symfony\Component\HttpFoundation\Response;

class InventoryRequest extends FormRequest
{
    protected function failedValidation(Validator $validator)
    {
        throw new HttpResponseException(response($validator->errors(), Response::HTTP_UNPROCESSABLE_ENTITY));
    }
}

【讨论】:

  • 明确的解决方案,非常感谢,在 Laravel 6.14 上工作正常
  • 我在 Laravel 8 中遇到了这个问题,这个方法对我有用。谢谢 T30
【解决方案2】:

我只是重写了failedValidation 函数

protected function failedValidation(Validator $validator)
{
    if ($this->wantsJson()) {
        throw new HttpResponseException(
            Response::error(__('api.validation_error'), 
            $validator->errors(), 
            470, 
            [], 
            new ValidationException)
        );
    }

    parent::failedValidation($validator);
}

所以我的自定义输出示例如下:

{
    "error": true,
    "message": "Validation Error",
    "reference": [
        "The device id field is required.",
        "The os version field is required.",
        "The apps version field is required."
    ],
}

BTW Response::error 在 laravel 中不存在。我使用宏来创建新方法

 Response::macro('error', function ($msg = 'Something went wrong', $reference = null, $code = 400, array $headers = [], $exception = null) {
      return response()->json(//custom here);
 });

【讨论】:

  • 你能分享Response类的完全分类命名空间吗
  • @Manojkiran.A Illuminate\Support\Facades\Response.
【解决方案3】:

我知道这篇文章有点陈旧,但我刚刚制作了一个中间件,用“application/json”替换了请求的“Accept”标头。这使得wantsJson() 函数在使用时返回true。 (这在 Laravel 5.2 中进行了测试,但我认为它在 5.1 中的工作原理相同)

这是你如何实现的:

  1. 创建文件app/Http/Middleware/Jsonify.php

    namespace App\Http\Middleware;
    
    use Closure;
    
    class Jsonify
    {
    
        /**
         * Change the Request headers to accept "application/json" first
         * in order to make the wantsJson() function return true
         *
         * @param  \Illuminate\Http\Request  $request
         * @param  \Closure  $next
         * 
         * @return mixed
         */
        public function handle($request, Closure $next)
        {
            $request->headers->set('Accept', 'application/json');
    
            return $next($request);
        }
    }
    
  2. 将中间件添加到 app/Http/Kernel.php 文件的 $routeMiddleware 表中

    protected $routeMiddleware = [
        'auth'       => \App\Http\Middleware\Authenticate::class,
        'guest'      => \App\Http\Middleware\RedirectIfAuthenticated::class,
        'jsonify'    => \App\Http\Middleware\Jsonify::class
    ];
    
  3. 最终在您的routes.php 中使用它,就像使用任何中间件一样。就我而言,它看起来像这样:

    Route::group(['prefix' => 'api/v1', 'middleware' => ['jsonify']], function() {
        // Routes
    });
    

【讨论】:

  • 我遇到了同样的问题,我想试试这个解决方案。我遇到的问题是,当我的控制器方法隐式加载我的 FormRequest 实例时,它与 Jsonify 中间件中修改的请求实例不同,因此想要有效地“重置”为 false。跨度>
  • FormRequest 扩展了 Request 所以它应该是同一个实例,可能显示一些代码
  • @SimonDepelchin 这个解决方案就像我在问题中提到的解决方案 2。
  • 是的,更多的细节和“Laravel 方式”恕我直言。
  • 此解决方案更好,因为它将所有内容都返回为 JSON。如果您使用 ApiRequest 发出未经授权的请求,它将返回 404 html 页面,但是这将返回 401 Unauthorized JSON 错误。
【解决方案4】:

如果您的请求具有 X-Request-With: XMLHttpRequest 标头或 accept content type as application/json,FormRequest 将自动返回包含错误的 json 响应,并带有状态为 422。

【讨论】:

    【解决方案5】:

    这让我大吃一惊,为什么在 Laravel 中很难做到这一点。最后,根据您重写 Request 类的想法,我想出了这个。

    app/Http/Requests/ApiRequest.php

    <?php
    
    namespace App\Http\Requests;
    
    
    class ApiRequest extends Request
    {
        public function wantsJson()
        {
            return true;
        }
    }
    

    然后,在每个控制器中传递\App\Http\Requests\ApiRequest

    public function index(ApiRequest $request)

    【讨论】:

    • 接受:标题中的 application/json 也可能对此有所帮助。
    • 我在测试 5.4 应用程序时遇到了这个问题。只需将此方法添加到 form request 即可。
    • “这让我难以置信”.......“这是一个超级简单的方法”,哈哈,这让我笑了。 +1
    • 它不起作用:这样的请求有空$request-&gt;all()
    • 这在工作或不工作的二元意义上有效,但考虑到问题的起草程度,这是一个真正缺乏光泽的解决方案。
    猜你喜欢
    • 2017-06-30
    • 2018-03-01
    • 2021-06-01
    • 2020-07-26
    • 2017-05-10
    • 2018-02-03
    • 1970-01-01
    • 2020-09-02
    • 2015-11-09
    相关资源
    最近更新 更多