Laravel put patch не работает

Laravel Form :: Model Binding — PUT / PATCH Update Routing не работает

У меня есть маршруты, настроенные для создания записи о человеке следующим образом:

Методы контроллера для генерации новой записи работают правильно и выглядят так:

СЕЙЧАС … моя проблема в том, чтобы заставить форму редактирования / обновления связываться должным образом …

Форма для обновления выглядит так

Я не могу получить форму для обновления записи, только смог создать новую запись. Кое-что о синтаксисе для связывания Form :: model, которое я не понимаю. Запрос PUT не выполняется, когда я передаю запрос в качестве аргумента, поэтому я не понимаю разницу между POST & PUT, как используется внутри Laravel, хотя я не уверен, что это моя проблема

Вот мой маршрут ремесленника: список

Решение

Ваш контроллер update подпись метода должна выглядеть следующим образом: $request в качестве первого аргумента и $id как второй. И я тоже консолидировал некоторую логику, но это необязательно.

Кроме того, это не имеет значения, учитывая, что структура URL идентична, но вы используете person.edit вместо person.update маршрут в вашей форме определения. Но я вижу, что у вас есть два маршрута под названием person.update , Один для PUT и другие PATCH , Вы можете быть осторожны, повторно используя те же имена маршрутов.

Наконец, если использовать Laravel Form помощники, вам не нужно добавлять csrf_field() сам. Это добавляется автоматически.

Другие решения

Я думаю, вы немного смущены. Прежде всего, вы должны понимать, как работают маршруты и контроллеры ресурсов.

Вы можете найти важную информацию для вашего понимания здесь:
Контроллеры ресурсов

Вы можете попробовать это:

routes.php

controller.php

form.blade.php

Как я вижу, вы используете только методы ресурса, поэтому я рекомендую использовать ресурсный маршрут с теми же действиями, которые перечислены в приведенной выше ссылке, например так:

Кроме того, не путайте представления (человека) с маршрутами (бодмейкер), потому что вы делаете их сочетание.

Вы должны установить method = «POST» формы и добавить в форму <> когда использовать PUT метод.

Источник

Laravel 6.8 PUT Method not working, Showing Blank Page

Laravel 6.8 PUT Method not working for one of Controller, Showing Blank Page

Any suggestion or solution are most welcome. Following are summery of code. Route Pointer is not going under Controller update function

HTML edit.blad.php ( I tested with << method_field('PUT') >> )

web.php ( Route File )

php artisan route:list http://prntscr.com/qf662i

Controller Function

Pointer not coming into controller update and showing only blank page I also tested with all function into the controller

For reference -> If I change web.php and do following code then pointer is coming there. But not into Controller update function.

5 Answers 5

As per your code everything looks good.

• You already tested PUT & PATCH variations as per expert suggestions here.
• You can get pointer into route file (web.php) but not into controller’s Any function >>> That means pointer is not passing to controller.

Reason for pointer not going into controller from route file

Your Path OR Name of controller is wrong / mismatched

Controller file is called from another place

Question

• Any BACKUP FOLDER or BACKUP CONTROLLER files stored there into ?? [ \app\Http\Controllers\ ]

If answer is YES then it might be possible that wrong controller from backup is called from laravel cache. REMOVE Those backup files and Folders from controller folder.

Solution

I think controller PATH is cached and wrong controller is called instead. Try following commands to clear general cache.

To clear controller file / path cache. We’ll have to regenerate autoload.

Try following command. (This step is important)

If this solves your issue then you can use normal html edit.blade form syntax as following.

On your controller. Your normal code should work like following.

Let me know if this process helps you. Good luck.

Источник

Patch, Post, Put методы какие когда применять Laravel 5.3?

Я понимаю что:
Patch — надо использовать когда обновляем 1 поле из 2 и более.
Put, когда изменяем все.
Post, когда мы не знаем сколько полей будем изменять.

Правильно ли я все понял?

• Вопрос задан более трёх лет назад
• 12340 просмотров

PUT — замена ресурса целиком.
PATCH — редактирование ресурса.

Не совсем понятна разница, в каком случае их применять. К примеру есть форма редактирования. Пользователь изменил только телефон, а если он изменил все поля. То есть на фронте нужно подменять запрос в зависимости от количества измененных полей или в каких моментах может понадобится put ?

Касательно этого, есть два ключевых момента:
1. Laravel передаёт данные либо POST либо GET, остальные варианты запросов «эмулируются» (по крайней мере, так было, хотя по моему, это проблема не Laravel’я, а браузеров, которые умеют отправлять форму только одним из двух выше описанных запросов)
2. Если у Вас в форме есть файлы, никаким другим методом, кроме как POST её передать не получиться, иначе, файлы таинственным образом растворятся.

Отсюда, можно сделать вывод, что варианты запросов, отличные от GET/POST — сделаны не более чем для удобства, и по правде говоря, в большей степени это нововведение разработчиков Laravel, в других фреймворках такие практики не особо развиты.

Таких правил, которые бы гласили о типе запроса в зависимости от количества измененных полей — нет, и на сервере (в рамках задачи обновления данных в БД) — разницы от того, каким запросом данные были получены — тоже нет. В те времена, когда проектировался и создавался протокол HTTP v1.0, о такой сложной логике как изменения типа запроса в зависимости от количества измененных в форме полей — не подозревали (хотя, я думаю, до такого и сейчас мало бы кто додумался). Большая часть запросов, за рамками GET и POST реализована для работы с «ресурсами» (читай «файлами») через HTTP-протокол и/или для каких-то более низкоуровневых задач, чем просто отправка формы.

В Laravel, в некоторых случаях, удобно использовать запросы, например, типа «DELETE» для удаления какого-то ресурса/записи/строки_в_бд, как альтернативу аналогичного GET-запроса, с постфиксом /delete (как пример), это немного разгружает логику контроллеров и позволяет шире задействовать логику системы роутинга, но не более того.

2. Если у Вас в форме есть файлы, никаким другим методом, кроме как POST её передать не получиться, иначе, файлы таинственным образом растворятся.

Из постмана в режиме «form-data» методом PUT передаю парметры и файл в ларавель контроллер.
Данные вижу только через var_dump(file_get_contents(‘php://input’));
В $request самого ларавеля этих данных не вижу. Появляются там, только когда меняю метод с PUT на POST.
Или я не понял, как их получить корректно или что, получается, если требуется передать файл, то методы patch, put меняем на post? 🙂

craigy_waigy, насколько я помню — отправить именно файлы через form-data можно только POST’ом, другие методы файлы к сожалению корректно не передают. Можно конечно извратиться, закодировать файл в какой-нибудь BASE-64 и передать как текст. но я бы пожалуй не стал так заморачиваться.

В качестве альтернативного варианта конкретно для Laravel’я — можно воспользоваться «хаком», который там существует довольно давно. Как известно, браузеры (HTML) умеют отправлять форму только методами GET и POST. Что мы максимально широко использовать остальные методы (PUT, DELETE и прочие) в Laravel, в форму можно добавить [скрытое] поле с именем «_method» и значением того метода, который нам нужен, например, «DELETE». Такие формы отправляются POST’ом, но на уровне роутинга Laravel — они будут обрабатываться как запросы указанного типа (в нашем примере — «DELETE»). Таким же образом можно соотв. отправлять и файлы, указывая «PUT»-метод.

Источник

Laravel Framework Russian Community

Пролог

Начало работы

Архитектурные концепции

Основное

Погружение

Безопасность

База данных

Eloquent ORM

Тестирование

Пакеты

Маршрутизация

Основы маршрутизации

Простейшие маршруты Laravel принимают URI и замыкание, обеспечивая нетрудоемкий и выразительный метод определения маршрутов и поведения без сложных конфигурационных файлов маршрутизации:

Файлы маршрутов по умолчанию

Все маршруты Laravel должны быть определены в файлах маршрутов, находящихся в вашем каталоге routes . Эти файлы автоматически загружаются вашим поставщиком App\Providers\RouteServiceProvider приложения. Файл routes/web.php определяет маршруты для вашего веб-интерфейса. Этим маршрутам назначается группа посредников web , которая обеспечивает такие функции, как состояние сессии и защита от CSRF. Маршруты в routes/api.php не сохраняют состояния и им назначается группа посредников api .

Для большинства приложений вы начнете с определения маршрутов в файле routes/web.php . К маршрутам, определенным в routes/web.php , можно получить доступ, введя URL-адрес определенного маршрута в вашем браузере. Например, вы можете получить доступ к следующему маршруту, перейдя по адресу http://example.com/user в своем браузере:

Маршруты, определенные в файле routes/api.php , вложены в группу маршрутов в RouteServiceProvider . Внутри этой группы автоматически применяется префикс URI /api , поэтому вам не нужно вручную добавлять его к каждому маршруту в файле маршрутов. Вы можете изменить префикс и другие параметры группы маршрутов, изменив свой класс RouteServiceProvider .

Доступные методы маршрутизатора

Маршрутизатор позволяет регистрировать маршруты, отвечающие на любой HTTP-метод:

Иногда требуется зарегистрировать маршрут, отвечающий на несколько HTTP-методов. Вы можете сделать это с помощью метода match . Или вы даже можете зарегистрировать маршрут, отвечающий на все HTTP-методы, используя метод any :

Внедрение зависимости

Вы можете объявить любые зависимости, необходимые для вашего маршрута, в сигнатуре замыкания вашего маршрута. Объявленные зависимости будут автоматически извлечены и внедрены в замыкание с помощью контейнера служб Laravel. Например, вы можете объявить класс Illuminate\Http\Request , чтобы текущий HTTP-запрос автоматически был внедрен в замыкание вашего маршрута:

Защита от CSRF

Помните, что любые HTML-формы, указывающие на маршруты POST , PUT , PATCH или DELETE , которые определены в файле маршрутов web , должны включать поле токена CSRF. В противном случае запрос будет отклонен. Вы можете прочитать больше о защите от CSRF в документации CSRF:

Маршруты перенаправлений

Если вы определяете маршрут, который перенаправляет на другой URI, то вы можете использовать метод Route::redirect . Этот метод имеет лаконичную запись, так что вам не нужно определять полный маршрут или контроллер для выполнения простого перенаправления:

По умолчанию Route::redirect возвращает код состояния 302 . Вы можете переопределить код состояния, используя необязательный третий параметр:

Или вы можете использовать метод Route::permanentRedirect для возврата кода состояния 301 :

При использовании параметров маршрута в маршрутах перенаправления, следующие параметры зарезервированы Laravel и не могут быть использованы: destination и status .

Маршруты представлений

Если ваш маршрут должен возвращать только HTML-шаблон, то вы можете использовать метод Route::view . Как и метод redirect , этот метод имеет лаконичную запись, так что вам не нужно полностью определять маршрут или контроллер. Метод view принимает URI в качестве первого аргумента и имя шаблона в качестве второго аргумента. Кроме того, вы можете указать массив данных для передачи в шаблон в качестве необязательного третьего аргумента:

При использовании параметров маршрута в маршрутах представлений, следующие параметры зарезервированы Laravel и не могут быть использованы: view , data , status и headers .

Параметры маршрута

Обязательные параметры

Иногда бывает необходимым отслеживание сегментов URI в вашем маршруте. Например, вам может потребоваться отследить идентификатор пользователя из URL-адреса. Вы можете сделать это, указав параметры маршрута:

Вы можете определить столько параметров маршрута, сколько потребуется для вашего маршрута:

Параметры маршрута всегда заключаются в фигурные скобки <> и должны состоять из буквенных символов. Подчеркивание ( _ ) также допускается в именах параметров маршрута. Параметры маршрута будут внедрены в замыкания маршрута / контроллеры в зависимости от их порядка, т.е. имена аргументов замыкания маршрута / контроллера не имеют значения.

Параметры и внедрение зависимости

Если у вашего маршрута есть зависимости, которые вы хотите, чтобы контейнер служб Laravel автоматически внедрил в замыкание вашего маршрута, то вы должны указать эти зависимости перед параметрами маршрута:

Необязательные параметры

Иногда может потребоваться указать параметр маршрута, который не всегда может присутствовать в URI. Вы можете сделать это, поставив знак ? после имени параметра. Не забудьте присвоить соответствующей переменной маршрута значение по умолчанию:

Ограничения регулярного выражения

Вы можете ограничить формат параметров вашего маршрута, используя метод where экземпляра маршрута. Метод where принимает имя параметра и регулярное выражение, определяющее, как параметр должен быть ограничен:

Для некоторых часто используемых шаблонов регулярных выражений есть соответствующие вспомогательные методы, позволяющие быстро добавлять их к вашим маршрутам:

Если входящий запрос не соответствует ограничениям шаблона маршрута, то будет возвращен 404 HTTP-ответ.

Глобальные ограничения

Если вы хотите, чтобы параметр маршрута всегда ограничивался конкретным регулярным выражением, то вы можете использовать метод pattern . Вы должны определить эти шаблоны в методе boot вашего класса App\Providers\RouteServiceProvider :

Как только шаблон определен, он автоматически применяется ко всем маршрутам, использующим это имя параметра:

Кодирование обратных слешей

Компонент маршрутизации Laravel позволяет всем символам, кроме обратного слеша ( / ), присутствовать в значениях параметров маршрута. Вы должны явно разрешить / быть частью заполнителя <> , используя регулярное выражение условия where :

Обратные слеши поддерживаются только в рамках последнего сегмента маршрута.

Именованные маршруты

Именованные маршруты позволяют легко создавать URL-адреса или перенаправления для определенных маршрутов. Вы можете указать имя для маршрута, связав метод name с определением маршрута:

Вы также можете указать имена маршрутов для действий контроллера:

Имена маршрутов всегда должны быть уникальными.

Создание URL-адресов для именованных маршрутов

После того, как вы присвоили имя указанному маршруту, вы можете использовать имя маршрута при генерации URL-адресов или перенаправлений с помощью вспомогательных глобальных функций route и redirect Laravel:

Если именованный маршрут определяет параметры, то вы можете передать параметры в качестве второго аргумента функции route . Указанные параметры будут автоматически подставлены в сгенерированный URL в соответствующие места:

Если вы передадите дополнительные параметры в массиве, то эти пары ключ / значение будут автоматически добавлены в строку запроса сгенерированного URL-адреса:

Иногда требуется указать значение по умолчанию для параметров URL запроса, например, текущий язык. Для этого вы можете использовать метод URL::defaults .

Получение информации о текущем именованном маршруте

Если вы хотите определить, был ли текущий запрос направлен на конкретный именованный маршрут, то вы можете использовать метод named экземпляра Route . Например, вы можете проверить имя текущего маршрута из посредника маршрута:

Группы маршрутов

Группы маршрутов позволяют совместно использовать атрибуты маршрута (например, посредники) для большого количества маршрутов без необходимости определять эти атрибуты для каждого маршрута отдельно.

Вложенные группы пытаются разумно «объединить» атрибуты со своей родительской группой. Посредники и условия where объединяются, а имена и префиксы добавляются. Разделители пространства имен и слеши в префиксах URI автоматически добавляются там, где это необходимо.

Посредники

Чтобы назначить посредника всем маршрутам в группе, вы можете использовать метод middleware перед определением группы. Посредники будут выполняться в том порядке, в котором они перечислены в массиве:

Маршрутизация поддоменов

Группы маршрутов также могут использоваться для управления маршрутизацией поддоменов. Поддоменам могут быть назначены параметры маршрута так же, как и URI маршрута, что позволяет вам отследить сегмент с поддоменом для использования его в вашем маршруте или контроллере. Поддомен можно указать, вызвав метод domain перед определением группы:

Чтобы обеспечить доступность маршрутов поддоменов, вы должны зарегистрировать маршруты поддоменов перед регистрацией маршрутов корневого домена. Это предотвратит перезапись маршрутами корневого домена маршрутов поддоменов, имеющих одинаковый путь URI.

Префиксы URI сгруппированных маршрутов

Метод prefix используется для подстановки указанного URI в качестве префикса каждому маршруту в группе. Например, можно подставить префикс admin перед всеми URI сгруппированных маршрутов:

Префиксы имен сгруппированных маршрутов

Метод name используется для подстановки указанной строки в качестве префикса имени каждому маршруту в группе. Например, можно подставить префикс admin перед всеми именами сгруппированных маршрутов. Данная строка создаст префикс имени маршрута точно в том виде, в котором он указан, поэтому мы обязательно укажем завершающий символ . в префиксе:

Привязка модели к маршруту

При внедрении идентификатора модели в маршрут или действие контроллера вы часто будете запрашивать базу данных, чтобы получить модель с соответствующим идентификатором. Привязка модели к маршруту Laravel обеспечивает удобный способ автоматического внедрения экземпляров модели непосредственно в ваши маршруты. Например, вместо того, чтобы внедрять идентификатор пользователя, вы можете внедрить весь экземпляр модели User с соответствующим идентификатором.

Неявная привязка

Laravel автоматически извлечет модели Eloquent, определенные в маршрутах или действиях контроллера, чьи имена переменных объявленного типа соответствуют имени сегмента маршрута. Например:

Так как переменная $user типизирована как модель App\Models\User Eloquent и имя переменной соответствует сегменту URI, то Laravel автоматически внедрит экземпляр модели с идентификатором, совпадающим со значением URI из запроса. Если соответствующий экземпляр модели не найден в базе данных, то автоматически будет сгенерирован 404 HTTP-ответ.

Конечно, неявная привязка также возможна при использовании методов контроллера. Опять же, обратите внимание, что сегмент URI соответствует переменной $user в контроллере, которая типизирована как App\Models\User :

Изменение ключа по умолчанию

По желанию можно извлекать модели Eloquent, используя столбец, отличный от id . Для этого вы можете указать столбец в определении параметра маршрута:

Если вы хотите, чтобы при извлечении класса связанной модели всегда использовался столбец базы данных, отличный от id , то вы можете переопределить метод getRouteKeyName модели Eloquent:

Измененный ключ и ограничения неявной привязки модели

При неявном связывании нескольких моделей Eloquent в одном определении маршрута бывает необходимо ограничить вторую модель Eloquent так, чтобы она была дочерней по отношению к предыдущей модели Eloquent. Например, рассмотрим это определение маршрута, которое извлекает пост в блоге по slug для конкретного пользователя:

При использовании неявной привязки с измененным ключом в качестве параметра вложенного маршрута, Laravel автоматически задает ограничение запроса для получения вложенной модели своим родителем, используя соглашения, чтобы угадать имя отношения родительской модели. В этом случае предполагается, что модель User имеет отношение с именем posts (форма множественного числа имени параметра маршрута), которое можно использовать для получения модели Post .

Настройка поведения при отсутствии модели

Обычно, если неявно связанная модель не найдена, то генерируется 404 HTTP-ответ. Однако вы можете изменить это поведение, вызвав метод missing при определении вашего маршрута. Метод missing принимает замыкание, которое будет вызываться, если неявно связанная модель не может быть найдена:

Явная привязка

Вам не обязательно использовать неявные привязки модели на основе соглашений Laravel, чтобы использовать привязку модели. Вы также можете явно определить, как параметры маршрута должны быть сопоставлены моделям. Чтобы зарегистрировать явную привязку, используйте метод маршрутизатора model , чтобы указать класс для переданного параметра. Вы должны определить ваши явные привязки модели в начале метода boot вашего класса RouteServiceProvider :

Затем определите маршрут, содержащий параметр :

Поскольку мы связали все параметры с моделью App\Models\User , экземпляр этого класса будет внедрен в маршрут. Так, например, при запросе users/1 будет внедрен экземпляр User из базы данных с идентификатором 1 .

Если соответствующий экземпляр модели не найден в базе данных, то автоматически будет сгенерирован 404 HTTP-ответ.

Изменение логики связывания

Если вы хотите определить свою собственную логику связывания модели, то вы можете использовать метод Route::bind . Замыкание, которое вы передаете методу bind , получит значение сегмента URI и должно вернуть экземпляр класса, который должен быть внедрен в маршрут. Опять же, эти изменения должны выполняться в методе boot поставщика RouteServiceProvider вашего приложения:

В качестве альтернативы вы можете переопределить метод resolveRouteBinding вашей модели Eloquent. Этот метод получит значение сегмента URI и должен вернуть экземпляр класса, который должен быть внедрен в маршрут:

Если в маршруте используется ограничения неявной привязки модели, то для получения связанной дочерней модели будет использоваться метод resolveChildRouteBinding родительской модели:

Резервные маршруты

Используя метод Route::fallback , вы можете определить маршрут, который будет выполняться, когда ни один другой маршрут не соответствует входящему запросу. Как правило, необработанные запросы автоматически отображают страницу 404 через обработчик исключений вашего приложения. Однако, поскольку вы обычно определяете резервный маршрут в своем файле routes/web.php , то все посредники группы web будет применены к этому маршруту. При необходимости вы можете добавить дополнительный посредник для этого маршрута:

Резервный маршрут всегда должен быть последним зарегистрированным маршрутом в вашем приложении.

Ограничение частоты запросов

Определение ограничителей частоты запросов

Laravel содержит мощные и настраиваемые службы ограничения частоты запросов, которые вы можете использовать для ограничения объема трафика для конкретного маршрута или группы маршрутов. Для начала вы должны определить конфигурации ограничителя, которые соответствуют потребностям вашего приложения. Как правило, это должно выполняться в методе configureRateLimiting класса App\Providers\RouteServiceProvider вашего приложения.

Ограничители определяются с помощью метода for фасада RateLimiter . Метод for принимает имя ограничителя и замыкание, которое возвращает конфигурацию ограничений, применяемых к назначенным маршрутам. Конфигурация ограничений – это экземпляры класса Illuminate\Cache\RateLimiting\Limit . Этот класс содержит полезные методы «построения», чтобы вы могли быстро определить свой «лимит». Имя ограничителя может быть любой строкой по вашему желанию:

Если входящий запрос превышает указанный лимит, то Laravel автоматически вернет ответ с 429 кодом состояния HTTP. Если вы хотите определить свой собственный ответ, который должен возвращаться, то вы можете использовать метод response :

Поскольку замыкание получает экземпляр входящего HTTP-запроса, то вы можете динамически создать ограничение на основе входящего запроса или статуса аутентификации пользователя:

Сегментация ограничений частоты запросов

Иногда может потребоваться сегментация ограничений по некоторым произвольным значениям. Например, вы можете разрешить пользователям получать доступ к указанному маршруту 100 раз в минуту на каждый IP-адрес. Для этого можно использовать метод by при построении лимита:

Множественные ограничения частоты запросов

При необходимости вы можете вернуть массив ограничений при указании конфигурации ограничителя. Каждое ограничение будет оцениваться для маршрута в зависимости от порядка, в котором они размещены в массиве:

Привязка ограничителей частоты запросов к маршрутам

Ограничители могут быть закреплены за маршрутами или группами маршрутов с помощью посредника throttle . Посредник throttle принимает имя ограничителя, которое вы хотите назначить маршруту:

Использование Redis для посредника throttle

Как правило, посредник throttle сопоставлен классу Illuminate\Routing\Middleware\ThrottleRequests . Это сопоставление определено в App\Http\Kernel вашего приложения. Если вы используете Redis в качестве драйвера кеша вашего приложения, то вы можете изменить это сопоставление, чтобы использовать класс Illuminate\Routing\Middleware\ThrottleRequestsWithRedis . Этот класс более эффективен при управлении ограничениями запросов с помощью Redis:

Подмена методов формы

HTML-формы не поддерживают действия PUT , PATCH или DELETE . Таким образом, при определении маршрутов PUT , PATCH или DELETE , которые вызываются из HTML-формы, вам нужно будет добавить в форму скрытое поле _method . Значение, отправленное с полем _method , будет использоваться как метод HTTP-запроса:

Для удобства вы можете использовать директиву @method шаблонизатора Blade для создания поля ввода _method :

Доступ к текущему маршруту

Вы можете использовать методы current , currentRouteName и currentRouteAction фасада Route для доступа к информации о маршруте, обрабатывающем входящий запрос:

Вы можете обратиться к документации API базового класса фасада Route и экземпляра Route, чтобы просмотреть все методы, доступные в классах маршрутизатора и маршрута.

Совместное использование ресурсов между источниками (CORS)

Laravel может автоматически отвечать на HTTP-запросы CORS OPTIONS значениями, которые вы сконфигурируете. Все параметры CORS могут быть настроены в конфигурационном файле config/cors.php вашего приложения. Запросы OPTIONS будут автоматически обрабатываться посредником HandleCors , который по умолчанию входит в ваш глобальный стек посредников. Ваш глобальный стек посредников находится в HTTP-ядре вашего приложения ( App\Http\Kernel ).

Для получения дополнительной информации о CORS и заголовках CORS обратитесь к веб-документации MDN по CORS.

Кеширование маршрутов

При развертывании вашего приложения на рабочем веб-сервере, вы должны воспользоваться кешем маршрутов Laravel. Использование кеша маршрутов резко сократит время, необходимое для регистрации всех маршрутов вашего приложения. Чтобы сгенерировать кеш маршрута, выполните команду route:cache Artisan:

После выполнения этой команды ваш файл кеша маршрутов будет загружаться при каждом запросе. Помните, что если вы добавляете какие-либо новые маршруты, то вам нужно будет сгенерировать новый кеш маршрутов. По этой причине вы должны запускать команду route:cache только во время развертывания вашего проекта.

Вы можете использовать команду route:clear для очистки кеша маршрута:

Источник