Ошибка 404 json

A friend pointed me towards a elegant solution that does not only handle 404 but also 500 errors. In fact, it handles every error. The key is, that every error generates an exception that propagates upwards through the stack of rack middlewares until it is handled by one of them. If you are interested in learning more, you can watch this excellent screencast. Rails has it own handlers for exceptions, but you can override them by the less documented exceptions_app config option. Now, you can write your own middleware or you can route the error back into rails, like this:

# In your config/application.rb
config.exceptions_app = self.routes

Then you just have to match these routes in your config/routes.rb:

get "/404" => "errors#not_found"
get "/500" => "errors#exception"

And then you just create a controller for handling this.

class ErrorsController < ActionController::Base
  def not_found
    if env["REQUEST_PATH"] =~ /^\/api/
      render :json => {:error => "not-found"}.to_json, :status => 404
    else
      render :text => "404 Not found", :status => 404 # You can render your own template here
    end
  end

  def exception
    if env["REQUEST_PATH"] =~ /^\/api/
      render :json => {:error => "internal-server-error"}.to_json, :status => 500
    else
      render :text => "500 Internal Server Error", :status => 500 # You can render your own template here
    end
  end
end

One last thing to add: In the development environment, rails usally does not render the 404 or 500 pages but prints a backtrace instead. If you want to see your ErrorsController in action in development mode, then disable the backtrace stuff in your config/enviroments/development.rb file.

config.consider_all_requests_local = false

Handling 404 Errors¶

We’re handling validation errors and invalid JSON errors. The last big thing
is to properly handle 404 errors. In showAction and updateAction,
we’re throwing a special type of exception class to trigger a 404 response.
But in reality, the 404 response isn’t JSON: it’s a big HTML page. You can
see this by browsing to a made-up programmer:

And actually, if we go to a completely made-up URL, we also see this same
HTML page:

Internally, Silex throws that same exception to cause this 404 page.

Somehow, we need to be able to return JSON for all exceptions and
while we are at it we should use the API problem detail format.

# features/api/programmer.feature
# ...

Scenario: Proper 404 exception on no programmer
  When I request "GET /api/programmers/fake"
  Then the response status code should be 404
  And the "Content-Type" header should be "application/problem+json"
  And the "type" property should equal "about:blank"
  And the "title" property should equal "Not Found"

// src/KnpU/CodeBattle/Application.php
// ...

public function configureListeners()
{
    $app = $this;

    $this->error(function(\Exception $e, $statusCode) use ($app) {
        // only act on /api URLs
        if (strpos($app['request']->getPathInfo(), '/api') !== 0) {
            return;
        }

        // ...

        return $response;
    });
}

// src/KnpU/CodeBattle/Application.php
// ...

$this->error(function(\Exception $e, $statusCode) use ($app) {
    // only act on /api URLs
    if (strpos($app['request']->getPathInfo(), '/api') !== 0) {
        return;
    }

    if ($e instanceof ApiProblemException) {
        $apiProblem = $e->getApiProblem();
    } else {
        $apiProblem = new ApiProblem($statusCode);
    }

    // ...
});

// src/KnpU/CodeBattle/Api/ApiProblem.php
// ...

public function __construct($statusCode, $type = null)
{
    $this->statusCode = $statusCode;
    $this->type = $type;

    if (!$type) {
        // no type? The default is about:blank and the title should
        // be the standard status code message
        $this->type = 'about:blank';
        $this->title = isset(Response::$statusTexts[$statusCode])
            ? Response::$statusTexts[$statusCode]
            : 'Unknown HTTP status code :(';
    } else {
        if (!isset(self::$titles[$type])) {
            throw new \InvalidArgumentException('No title for type '.$type);
        }

        $this->title = self::$titles[$type];
    }
}

// src/KnpU/CodeBattle/Application.php
// ...

$this->error(function(\Exception $e, $statusCode) use ($app) {
    // ...

    $response = new JsonResponse(
        $apiProblem->toArray(),
        $statusCode
    );
    $response->headers->set('Content-Type', 'application/problem+json');

    return $response;
});

// src/KnpU/CodeBattle/Application.php
// ...

$data = $apiProblem->toArray();
if ($data['type'] != 'about:blank') {
    $data['type'] = 'http://localhost:8000/api/docs/errors#'.$data['type'];
}
$response = new JsonResponse(
    $data,
    $statusCode
);

# features/api/programmer.feature
# ...

Scenario: Error response on invalid JSON
  # ...
  And the "type" property should contain "/api/docs/errors#invalid_body_format"

This tutorial uses a deprecated micro-framework called Silex. The fundamentals of REST are still ? valid, but the code we use can’t be used in a real application.

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "silex/silex": "~1.0", // v1.3.2
        "symfony/twig-bridge": "~2.1", // v2.7.3
        "symfony/security": "~2.4", // v2.7.3
        "doctrine/dbal": "^2.5.4", // v2.5.4
        "monolog/monolog": "~1.7.0", // 1.7.0
        "symfony/validator": "~2.4", // v2.7.3
        "symfony/expression-language": "~2.4" // v2.7.3
    },
    "require-dev": {
        "behat/mink": "~1.5", // v1.5.0
        "behat/mink-goutte-driver": "~1.0.9", // v1.0.9
        "behat/mink-selenium2-driver": "~1.1.1", // v1.1.1
        "behat/behat": "~2.5", // v2.5.5
        "behat/mink-extension": "~1.2.0", // v1.2.0
        "phpunit/phpunit": "~5.7.0", // 5.7.27
        "guzzle/guzzle": "~3.7" // v3.9.3
    }
}

In this short article, we will learn how we can handle 404 error for API as well as webpage. While building API, we need JSON response with the useful message whereas in web page load, we need a 404 page. We can achieve this with a few lines of code.

First of all, we will try the route method. In this method, we will add the below code at the end of api.php to handle the routes if non of the above routes are matched. What it does is basically if non of the routes are matched, it catches the route and returns a JSON response with a message instead of a 404 page.

Route::any('{path}', function() {
    return response()->json([
        'success' => false,
        'message' => 'Route not found'
    ], 404);
})->where('path', '.*');

However, this has some limitations. If there are packages where routes are defined then those routes will never hit because the api.php is rendered first and the packages’ routes are rendered. Thus, it won’t work under those conditions. Thus, below methods works perfectly fine for all conditions.

To handle the limitation of the above code, we will customize handler.php file. The limitation of the below code is that you need to have your API route prefix with “/api/”. Simply add the below code in your app/Exceptions/Handler.php.

//import class on the top
use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

public function render($request, Exception $exception)
{
    if ($exception instanceof NotFoundHttpException) {
        if ($request->is('api/*')) {
            return response()->json(['error' => 'Not Found'], 404);
        }
        return response()->view('404', [], 404);
    }
    return parent::render($request, $exception);
}

What it does is that, if there is an exception that is an instance of NotFoundHttpException and if the request has “/api/” in its route, then the JSON response of Route not found will be returned.

Read More Articles

A useful feature that shipped in Laravel 5.5 is fallback routing. You can learn about fallback routing in Better 404 responses using Laravel +5.5 by Mohamed Said (the author of the feature) to get the full picture of why it’s useful and how to use fallback routes.

When you are creating an API, you probably want a 404 route that responds with JSON (or whatever format you are serving via content negotiation) instead of the default 404 JSON response.

Here’s what you get if you request an undefined route with a JSON content type:

curl \
-H"Content-Type:application/json" \
-H"Accept: application/json" \



  


                       
  



-i http://apidemo.test/not/found
HTTP/1.1 404 Not Found
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: no-cache, private
Date: Thu, 16 Aug 2018 06:00:42 GMT
{
    "message": ""



  


                       
  



}

You can see that we get an empty message that isn’t necessarily super helpful, but the framework returns valid JSON without any work on our part. Let’s cover a couple of scenarios and walk through how you can ensure your API responds with a fallback 404 response with a useful message when an API route doesn’t match.

Setup

Using the Laravel CLI, we’ll create a new project to walk through adding a 404 response to your API:

laravel new apidemo
cd apidemo/
# Valet users...
valet link

We’ll configure a MySQL database for this project:

mysql -u root -e'create database apidemo'

Update the .env to the credentials that match your database environment, for me it would be:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=apidemo
DB_USERNAME=root
DB_PASSWORD=

We’re going to use the users table to demonstrate a few things. Update the database/seeds/DatabaseSeeder.php to the following:

<?php
use Illuminate\Database\Seeder;
class DatabaseSeeder extends Seeder



  


                       
  



{
    /**
     * Seed the application's database.
     *
     * @return void
     */
    public function run()
    {
        factory('App\User', 10)->create();
    }



  


                       
  



}

Finally, you can run migrations and the seeder:

php artisan migrate:fresh --seed

API Routes

We’ll set up a few API routes, including the fallback route for our API, complete with a test. First, let’s create the following test:

php artisan make:test Api/FallbackRouteTest

Add a test case to look for a JSON response and verify a 404 error:

<?php
namespace Tests\Feature\Api;
use Tests\TestCase;
use Illuminate\Foundation\Testing\WithFaker;



  


                       
  



use Illuminate\Foundation\Testing\RefreshDatabase;
class FallbackRouteTest extends TestCase
{
    /** @test */
    public function missing_api_routes_should_return_a_json_404()
    {
        $this->withoutExceptionHandling();
        $response = $this->get('/api/missing/route');
        $response->assertStatus(404);
        $response->assertHeader('Content-Type', 'application/json');



  


                       
  



        $response->assertJson([
            'message' => 'Not Found.'
        ]);
    }
}

If you run the test suite at this point this test will fail because we haven’t defined a fallback route:

phpunit --filter=ApiFallbackRouteTest
...
There was 1 error:
1) Tests\Feature\ApiFallbackRouteTest::missing_api_routes_should_return_a_json_404



  


                       
  



Symfony\Component\HttpKernel\Exception\NotFoundHttpException: GET http://localhost/api/missing/route

Let’s define a fallback route at the end of the routes/api.php file:

Route::fallback(function(){
    return response()->json(['message' => 'Not Found.'], 404);
})->name('api.fallback.404');

We’ve created a fallback route that responds with JSON and returns a message which we assert in our test. We also assert the content type to be application/json as well.

Note the name that we’ve defined for the route api.fallback.404. We’ll need to use this name shortly to respond to a few exception types in our exception handler.

A Valid Users Endpoint

To illustrate further how the fallback route is used, we’ll define a valid route for our User model:

Route::get('/users/{user}', 'UsersController@show')
    ->name('api.users.show');



  


                       
  

Next, we’ll create a controller and user resource:

php artisan make:controller UsersController
php artisan make:resource User

We rely on implicit route model binding, and our controller uses the User resource to respond with JSON:

<?php
namespace App\Http\Controllers;
use App\User;
use App\Http\Resources\User as UserResource;
use Illuminate\Http\Request;
class UsersController extends Controller



  


                       
  



{
    public function show(User $user)
    {
        return new UserResource($user);
    }
}

Next, we’re going to create a test to verify the user endpoint and also verify that we get a 404 back when we request an invalid user:

php artisan make:test Api/ViewUserTes

This is where it gets interesting: let’s create a test to verify our route triggers a ModelNotFoundException via route model binding:

<?php



  


                       
  



namespace Tests\Feature\Api;
use Tests\TestCase;
use Illuminate\Foundation\Testing\WithFaker;
use Illuminate\Database\Eloquent\ModelNotFoundException;
use Illuminate\Foundation\Testing\RefreshDatabase;
class ViewUserTest extends TestCase
{
    /** @test */
    public function requesting_an_invalid_user_triggers_model_not_found_exception()
    {



  


                       
  



        $this->withoutExceptionHandling();
        try {
            $this->json('GET', '/api/users/123');
        } catch (ModelNotFoundException $exception) {
            $this->assertEquals('No query results for model [App\User].', $exception->getMessage());
            return;
        }
        $this->fail('ModelNotFoundException should be triggered.');
    }
}



  


                       
  

This test is valid and should pass—it’s mostly making sure that somehow our controller is either using route model binding or is triggering a model exception somehow. We’ll come back to it in a second, but note that you may want a custom response message for the ModelNotFoundException.

A somewhat redundant test, we will not disable exception handling and make sure we are getting back a 404 and the “no query results” error message back from the API:

/** @test */
public function requesting_an_invalid_user_returns_no_query_results_error()
{
    $response = $this->json('GET', '/api/users/123');
    $response->assertStatus(404);
    $response->assertHeader('Content-Type', 'application/json');
    $response->assertJson([
        'message' => 'No query results for model [App\User].'



  


                       
  



    ]);
}

At this point both tests should be passing—we didn’t necessarily use TDD to drive out the route model binding.

Next, let’s write a failing test for our route model binding which ensures an invalid user id doesn’t match the route, and we get the fallback route:

/** @test */
public function invalid_user_uri_triggers_fallback_route()
{
    $response = $this->json('GET', '/api/users/invalid-user-id');
    $response->assertStatus(404);
    $response->assertHeader('Content-Type', 'application/json');



  


                       
  



    $response->assertJson([
        'message' => 'Not Found.'
    ]);
}

If you run this test you’ll get (partially) the following error:

Failed asserting that an array has the subset Array &0 (
    'message' => 'Not Found.'
).
--- Expected
+++ Actual



  


                       
  



@@ @@
 Array
 (
-    [message] => Not Found.
+    [message] => No query results for model [App\User].

We can get this test passing by constraining the {user} route parameter:

Route::get('/users/{user}', 'UsersController@show')
    ->name('api.users.show')
    ->where('user', '[0-9]+');

If you run the test it will be passing, thus, successfully hitting the API fallback route:

phpunit --filter=invalid_user_uri_triggers_fallback_route
...
OK (1 test, 4 assertions)

It’s a good idea to add conditions to your route parameters so that the route will only match valid parameters and hit the fallback route otherwise. If using a fallback isn’t essential to you, the route model binding will still return a 404 error, but some databases might trigger an error while querying a table with an invalid value.

You would probably have something like this test as well, ensuring that your endpoint works for valid users:

use RefreshDatabase;
/** @test */
public function guests_can_view_a_valid_user()
{
    $user = factory('App\User')->create([



  


                       
  



        'name' => 'LeBron James',
        'email' => 'lebron@lakers.com',
    ]);
    $response = $this->json('GET', "/api/users/{$user->id}");
    $response->assertOk();
    $response->assertJson([
        'data' => [
            'name' => 'LeBron James',
            'email' => 'lebron@lakers.com',
        ]



  


                       
  



    ]);
}

Customizing ModelNotFoundException Responses

You might be fine with the error message that the API responds with when a ModelNotFoundException is triggered through our route model binding. If you’re interested in triggering the fallback route, you could update the exception handler with a check that resembles the following:

# app/Exceptions/Handler.php
use Illuminate\Database\Eloquent\ModelNotFoundException;
use Illuminate\Support\Facades\Route;
public function render($request, Exception $exception)
{
    if ($exception instanceof ModelNotFoundException && $request->isJson()) {
        return Route::respondWithRoute('api.fallback.404');
    }
    return parent::render($request, $exception);



  


                       
  



}

Again, this is an optional step that gives you an idea of how you can use exception handling coupled with a fallback route. You might be perfectly fine with the JSON response provided by default for a ModelNotFoundException. The main point is demonstrating how to use fallback routes from the exception handler.

If you update the exception handler to include the check for a model not found, you’ll need to update the broken test to match the fallback response to get the test passing again.

Learn More

I’d encourage you to read through Mohamed Said’s Better 404 responses using Laravel +5.5 post and his pull request for the feature 5.5 Add ability to set a fallback route by themsaid . Our release announcement post Laravel 5.5.5 Released With a New Route Fallback to Help Customize Your 404 Views has more information on this feature as well.

The following document provides reference information about the status codes
and error messages that are used in the Cloud Storage JSON API. For
the page specific to the Cloud Storage XML API, see
HTTP status and error codes for XML.

Error Response Format

Cloud Storage uses the standard HTTP error reporting format for the
JSON API. Successful requests return HTTP status codes in the 2xx range. Failed
requests return status codes in the 4xx and 5xx ranges. Requests that require a
redirect returns status codes in the 3xx range. Error responses usually include
a JSON document in the response body, which contains information about the
error.

The following examples show some common errors. Note that the header
information in the responses is omitted.

401 Unauthorized

{
"error": {
 "errors": [
  {
   "domain": "global",
   "reason": "required",
   "message": "Login Required",
   "locationType": "header",
   "location": "Authorization"
  }
 ],
 "code": 401,
 "message": "Login Required"
 }
}

403 Forbidden

{
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "forbidden",
    "message": "Forbidden"
    }
  ],
  "code": 403,
  "message": "Forbidden"
 }
}

404 Not Found

{
"error": {
 "errors": [
  {
   "domain": "global",
   "reason": "notFound",
   "message": "Not Found"
  }
 ],
 "code": 404,
 "message": "Not Found"
 }
}

409 Conflict

{
"error": {
 "errors": [
  {
   "domain": "global",
   "reason": "conflict",
   "message": "You already own this bucket. Please select another name."
  }
 ],
 "code": 409,
 "message": "You already own this bucket. Please select another name."
 }
}

The following table describes the elements that can appear in the response body
of an error. Fields should be used together to help determine the problem.
Also, the example values given below are meant for illustration and are not an
exhaustive list of all possible values.

HTTP Status and Error Codes

This section provides a non-exhaustive list of HTTP status and error codes that
the Cloud Storage JSON API uses. The 1xx Informational and 2xx
Success codes are not discussed here. For more information, see Response Status
Codes in RFC 7231 §6, RFC 7232 §4,
RFC 7233 §4, RFC 7235 §3, and RFC 6585.

302—Found

303—See Other

304—Not Modified

307—Temporary Redirect

308—Resume Incomplete

400—Bad Request

401—Unauthorized

403—Forbidden

404—Not Found

405—Method Not Allowed

408—Request Timeout

409—Conflict

410—Gone

411—Length Required

412—Precondition Failed

413—Payload Too Large

416—Requested Range Not Satisfiable

429—Too Many Requests

499—Client Closed Request

500—Internal Server Error

502—Bad Gateway

This error is generated when there was difficulty reaching an internal service.
It is not formatted with a JSON document. You should retry the request
using truncated exponential backoff.

503—Service Unavailable

504—Gateway Timeout

This error is generated when there was difficulty reaching an internal service.
It is not formatted with a JSON document. You should retry the request
using truncated exponential backoff.