Разделение API для разных типов клиентов

Во многих проектах, где было несколько типов клиентов, например Web, Mobile и например публичный доступ к данным. В этих проектах мы использовали единое АПИ для всех подключений. Но в этом варианте как есть плюсы, так и минусы. Плюсом является то что мы упрощаем поддержку, имея только один backend для всего. Минусом является зависимость этих сервисов друг от друга. Например если мы вносим какое-то изменение для версии web, то мы должны быть уверены, что это изменение совместимо с другими клиентами. Еще из-за такой зависимости у нас была проблема с тем, что API часто попадало под DDOS атаку через web форму и тем самым все остальные клиенты тоже страдали. В связи с этим, мы решили разделить в первую очередь Public API. Вынеся туда основные методы для работы с нашим сервисом и уведомив всех партнеров об этом. НО с мобильным приложением стало сложнее. Поскольку URL обращения был зашит внутри билда аппки. Следовательно мы могли этот url поменять только в следующей версии, но не факт что все пользователи обновятся на новое приложение и поэтому мы обязаны были поддерживать уже 2 варианта АПИ для мобильного приложения. Стало ли нам от этого проще жить? И да и нет, со временем мы все таки избавились от старых методов для мобилки, но на это потребовался очень долгий период, чтобы убедиться, что более 90% наших пользователей уже перешли на новую версию. Такие архитектурные изменения всегда боль, но они необходимы, как говорится “Меняйся или умри”. В новых проектах я стал сразу разделять эти АПИ, во многих случаев я просто дублирую сервис на еще один поддомен для каждого типа клиента и таким образом, в будущем если потребуется вносить конкретные изменения для одного из типов клиента, это не внесет дополнительных проблем с миграцией и версионированием. Обсуждаем тут: @kyb_chat Подписываемся тут: @knowyourbackend