Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

Роман Юрьевич Ипатьев, приведи пример проблемного кода. У тебя есть либо пользовательский ввод, либо свой (программиста). Какая может быть ситуация, что твоя модель получит не те данные, которые ты, как программист написал? И зачем это называть "валидацией". В статье, автор реально валидирует емейлы итд что бред полный, учитывая функционал Ларавел.

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

NubasLol, ну и пускай делают что хотят. База же локальная. Или ты на проде статусы через консоль меняешь? а если эти люди напишут delete all здесь чего делать? В любом случае это к валидации не имеет никакого отношения.

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

NubasLol, еще через AdminController. Я понял) Для этого в Ларавел FormRequest class. Зачем тебе нужна валидация в консоли? Себе не доверяешь чтоли? или у теюбя юзеры консоль юзают?)

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

NubasLol, зачем тебе в консоли валидация?

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

NubasLol, StoreOrderRequest это класс https://laravel.com/docs/8.x/validation#form-reque.... Его можно использовать в неограниченном числе мест.

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

NubasLol, в OrderRequest правило exists. А в чем проблема не догоняю?)

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

NubasLol, ты только что описал два процесса валидации, разделив на основную и не основную. Если тебе нужно изменить данные перед валидацией для этого есть prepareForValidation. Если нужно изменить данные перед записью в бд - меняй. Пользователь и валидация тут не причем. Валидация проверяет пользовательский ввод, который тебе нужен для дальнейшей логики. А для подстраховок и закрепления функционала есть тесты.

Где в Laravel лучше делать валидацию входящих данных - в контроллере или сделать кастомный Request для контроллера, или Middleware?

Двойная валидация это мощно.

Почему так странно работает findOrFail()?

Действительно, проверять findOrFail еще надо додуматься. Решение всегда было. см доку и мой ответ. Как его использовать решает программист. Например запихиваешь в массив ключи/name урлов и сообщения, форычишь http ексепшен и получаешь нормальные сообщения, даже с переводами. id в реквесте также присутствует.

Почему так странно работает findOrFail()?

Роми, неправильно посылать юзеру название модели вместо нормального сообщения. А с findOrFail все логично - после ошибки с моделью вызывается 404 http, как и обещано в доке.

Почему так странно работает findOrFail()?

Роми, все в Ларавел логично и правильно. Сначала ModelNotFoundException затем NotFoundHttpException, который и рендерится при 404. Ты походу вертикально читаешь. Я уже писал, что запрос может не иметь модели. Так что иссую твою отправят в корзину.

Почему так странно работает findOrFail()?

Роми, что юзер будет делать с названием модели и айдишником? Это техническая инфа для разработчика. Юзерфрендли в этом ноль. И запросы могут не иметь модели. А некоторые могут иметь несколько моделей. Короче бред на бреде.

Почему так странно работает findOrFail()?

Роми, да нет костыль как раз getModel, а универсальное решение это отдать шаблон 404 с сообщением страница не найдена, как делают все нормальные люди

Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Роми, 500 ошибки вообще нет никакого смысла расшифровывать. Бред. Их вообще быть не должно. Максимум написать ошибка сервера. Ну или включай дебаг тру на проде и расшифровывай по полной. А для 404 достаточно шаблона https://qna.habr.com/q/52852525252 или обрабатывать как написано в документации, а не в каких-то левых статьях.

Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Mellorn, там вызов someMethod на null) Вместо model binding или findOrFail

Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Роми, 500 ошибка это 500 ошибка, инфа там для юзера одна - ошибка сервера. Подробности для разработчика в логе. Код ответа есть на фронте можно менять дизайн как хочешь. Или здесь https://laravel.com/docs/8.x/errors#rendering-exce...

Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Роми, данное сообщение Ларавел возвращает автоматом

Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Роми, в статье бред и говнокод. Ларавел это фреймворк для веб приложений. Наверное, там задумывались о возврате ошибок.

Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Это типа лайвхак, как трейтами пользоваться? Очень интересно.

Laravel как правильно составить БД запрос?

Иван, запрос делаешь от PaymentHistory раз конечные данные его нужны. Там whereHas на hasOne отношение ByHistory, чтобы отфильтровать по статусу и дате. потом sum. т.е. вместо join юзать отношения https://laravel.com/docs/8.x/eloquent-relationship...