+ @KasyanovSergey

thmskor (61.95) увеличил карму KasyanovSergey (1030.8)

+ @slipgrom, хорошая статья про api

ichishkala (174.24) увеличил карму slipgrom (715.98)

+ @slipgrom но! Раскрыто не полностью) почему забыл про штатные ларавелерские ресурс контроллеры и ресурсы ответов ?)

Так же при разработке API особенно RESTful (не путать с REST-Like который описан в статье, так как используется пока только get метод) исключения как правило реализуются кастомные от единого родителя. Что позволят зарегистрировать его поведение один раз в Plugin.php и предоставить ему представление самого себя в ответе по собственной логике.

Однако статья хорошая! Хорошо что такие стали появляться под октябрь :)

LeMaX10 (4217.15) увеличил карму slipgrom (780.92)

Главное чтобы винтер не стибзили на свой лад ))

>почему забыл про штатные ларавелерские ресурс контроллеры и ресурсы ответов

В статье написано, что основа разработки - как в ларе потому ресурсные контроллеры, ресурсы ответов и форм реквесты не описаны.
Идея была - описать именно особенности в октобере, а конкретно - обработку ошибок, которая работает только для апи роутов и корс, который в новой ларе есть, а в 6 - нет

>не путать с REST-Like который описан в статье, так как используется пока только get метод

Опять же, в статье - только пример, никто не мешает добавить остальные http методы

>исключения как правило реализуются кастомные от единого родителя

1) Никто не мешает зарегать остальные
2) Как ты изменишь родителя того же ApplicationException?

>Никто не мешает зарегать остальные

ну и у себя мы используем вариант посложнее, ловится Throwable, а дальше несколько хендлеров на разные типы с проверкой через instanceof и фоллбэк для всех остальных

Обработка ошибок нормально работает и в 6 ларе с этим проблем нет. От 7 не много отличий в этом плане, особенно в плане рест ресурсов. Про рест ресурсы я упомянул, так как это основной стандарт ларки, и в статье было бы не плохо так же увидеть их, темболее что они отражают логику API во всех приятных деталях.

Про дополнить - читать до конца в скобках. Это и так ясно.

Регать остальные не нужно, только 1, который является родителем APIException например, который представит метод response для представления самого себя в ответе и от которого остальные эксепшены API
ApplicationException не может являться исключением для API, так как его основное предназначение исключение приложения, которое в добавок не регистрируется в логах насколько помню по документации, что для API сразу не подходит.

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

ApplicationException - лишь пример системного исключения. Ошибка валидации - ровно та же проблема. Можно конечно вручную все првоерять и бросать свой эксепш, который будет наследоваться от какого-то одного ApiException, но как тогда быть с FormRequest который сам все валидирует?

>Обработка ошибок нормально работает и в 6 ларе с этим проблем нет.

работать то она работает, но в ответе инфы почти никакой нет

У форм реквеста есть метод который возвращает результат ошибки. Одно базовое переопределение.

Ни разу не видел проблем и темболее не увидел разницы с 7 веткой :(

И тем не менее зарегать свой хендлер на каждый exception все равно можно. middleware и правда не лучшее место для этого, но так мы можем навесить хендлеры только на нужную группу роутов.

Теперь страшно следующий гайд публиковать :)

У каждого свою путь :)

Я больше не буду комментировать) только плюсики ставить )

+ по graphQL тоже не помешало бы