@verygoodboy

Где правильно выполнять проверку try/catch для внешних api в Laravel?

Я стремлюсь переносить логику из контроллеров в сервисы или екшны, а в контроллерах принимать запрос и отдавать ответ. Но есть случаи, когда необходимо работать с внешними api. Например:
$client = new \GuzzleHttp\Client();
$response = $client->request('GET', 'https://site.com/api...');
// ... логика

Но внешний api сервис может быть недоступным. Поэтому, необходимо использовать try catch.
try {
    $client = new \GuzzleHttp\Client();
    $response = $client->request('GET', 'https://site.com/api...');
} catch (RequestException $ex) {
    // выброс ошибки $ex
}

Где правильно выполнять проверку try catch в контроллере или в сервисе если логика одного метода может иметь несколько обращений к api?
  • Вопрос задан
  • 242 просмотра
Решения вопроса 1
ipatiev
@ipatiev Куратор тега PHP
Потомок старинного рода Ипатьевых-Колотитьевых
Как вам правильно написали в комментариях, в общем случае ловить исключение надо конечно в сервисе.
Иначе у ваших компонентов будет высокая связанность (copuling) компонентов, а надо чтобы она была наоборот - низкая. "Все, что случилось в Вегасе, осталось в Вегасе".

Если ловить в контроллере, то вы увязываете вместе уже 4 разные сущности:
- внешний сервис
- Газл
- сервис
- ещё и контроллер
Не многовато?
Получается, что контроллер должен что-то там знать про всех троих предыдущих. А он по идее должен знать только про непосредственного собеседника - сервис.
Так что ответ тут в общем случае очевиден.

Также в комментариях вы пишете, что контроллер у вас общается с несколькими сервисами. Это понижает его связность (cohesion). А она наоборот, должна быть высокой. В смысле он должен делать что-то одно.
Поэтому решение, опять же, очевидно - все эти пертурбации с передачей горячей картофелины из сервиса в сервис должны производиться еще одном сервисе. Потому что это безнис-логика. А в конроллере не должно быть бизнес-логики. Контроллер - это чисто брокер НТТР запросов. Принять данные, проверить их, и передать в модель. То есть туда, где пишется бизнес-логика - все эти "сходить в тот сервис, передать в другой и сообщить третьему".
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы