Comments 11
Упс, видимо с первой попытки не так понял, возражение снимается.
import { httpAPIv1Article  } from 'services'

И тут выходит API v2 и мы меняем все вызовы по всему проекту?

Смена мажорной версии API подразумевает отсутствие обратной совместимости и, если не замену, то просмотр всех вызовов к нему. В случае же смены лишь минорной версии, замена будет представлять из себя что-то вроде замены строки
import { httpAPIv1Article  } from 'services_v1_0'
на
import { httpAPIv1Article  } from 'services_v1_1'
Да, в этом-то и дело, что изменяя версию API, мы можем подключить обновленный модуль, не меняя при этом обработчики данных (если конечно структура API кардинально не меняется)

Жесть, сочувствую тем кто работает после вас с вашим кодом.

вызывая httpGift, применяются переданные параметры
Что такое «вызывая применяются»?
«Подъезжая к сией станцыи и глядя на природу в окно, у меня слетела шляпа»?
А создать слой API с объектами и методами в них для получения/отправки данных, и в settings вынести «настройкой» версию API и списки url уже считается плохим тоном?

Не поймите не правильно, но сопровождать запутанный код всегда сложно. Я когда разрабатываю приложение, то стараюсь к минимуму свести связанность. И конкретно для API делаю так, что бы можно было что либо поменять в настройках, не затрагивая приложение.
Это решение выглядит как реализация слоя API и не исключает конфигурирования дополнительного.
Я бы сказал, что это лишь наглядный пример пользы каррирования на примере работы с API. Тут как всегда, под каждую задачу (команду) могут быть найдены разные оптимальные решения, это одно из.
Only those users with full accounts are able to leave comments. Log in, please.