IS
тоже верно.
Size: a a a
2020 June 28
a
а что мешает сделать несколько частей api?
IS
Получается, в классе API надо делать какую-то структуру, которая будет разбирать - если приехал реквест класса A - послать его так-то, если реквест класса B - то так-то.
T🐜
Тут просто может понадобится трансформ в жсон или хмл. Тогда тебе придется вырезать урл с дто
a
вроде
api->user->register($data)
api->workDay->end($id)
api->user->register($data)
api->workDay->end($id)
IS
так.
где будет в этом случае храниться инстанс httpClient?
где будет в этом случае храниться инстанс httpClient?
IS
будь то гуззл или yii2-httpclient или кто угодно.
С
чет выглядит слишком замудренно, чем замудрённей тем ненадёжней)
a
хз к кому вопрос)
IS
atcq (Алексей)
вроде
api->user->register($data)
api->workDay->end($id)
api->user->register($data)
api->workDay->end($id)
где будет в этом случае храниться инстанс httpClient?
T🐜
atcq (Алексей)
вроде
api->user->register($data)
api->workDay->end($id)
api->user->register($data)
api->workDay->end($id)
Пытался так делать давно. Это для очень трудолюбивых )) клиент для апи будет очень жирный )))
a
в корне пусть хранится и передается в подапи объекты через конструктор, например, или отдельным сервисом с низкоуровневой отправкой
a
те. апи клиент высокоуровневый, а сам guzzl может в отдельном сервисе рядом лежать и им использоваться
T🐜
где будет в этом случае храниться инстанс httpClient?
Инжектится в конструктор клиента. Через di 😄
IS
Не. В моём случае это будет столько подапи, сколько собственно запросов )
T🐜
Подключаешь в конфиге газзл и збс
a
ну дело твое, так-то без группировки сложно
a
особенно когда файлик с апишкой на 2к строк становится )
IS
atcq (Алексей)
ну дело твое, так-то без группировки сложно
было бы просто - я бы не пришёл за помощью зала )
a
тогда реализуй не dto, а механизм команд