@non_existing

Хороша ли идея выноса работы с интерфейсом на единый API?

Собственно, стоит в задачах привести в порядок и проапгрейдить один высоконагруженный проект. В основе - самописный фреймворк, что слегка утяжеляет задачу. Но это всё вводное, а вопрос вот в чем:

Одной из задач стоит создание API для подключение мобильного приложения с доступом к личному кабинету и статистики. Насколько адекватна идея для разделения сфер ответственности и упрощения всего этого на бекенде реализовать один универсальный API, на который бы были завязаны как интерфейс (обращающийся в итоге через REST), так и мобильная прила? В голове смотрится все это очень уж красиво - единая точка входа, единая документация, небольшая адаптация в API исходя из происхождения запроса, влияющая на тип аутенфикации и необходимость CSFR-проверки.

Чем чревата такая попытка завязать все воедино?
  • Вопрос задан
  • 82 просмотра
Решения вопроса 2
@Yan-s
Есть несколько сложностей, вот парочка.

Нередко бывает, что функционал мобильного приложения требует некоторой другой логики работы, например он часто бывает упрощен.

Если API раздельное, вы можете гибко и без особых опасений вносить какие то изменения в работу API браузерной версии не задевая мобильное приложение. Последнее всегда более требовательно к стабильности API, поскольку если вы нарушите обратную совместимость не достаточно просто обновить сборку приложения, необходимо еще чтобы пользователи обновили его на своих устройствах.
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Вы используйте один логический модуль как для сайта, так и для мобильного приложения. А вот рендер - уже делаете в зависимости от типа клиента. Поэтому изменения выдачи в браузер или через API для мобильного устройства никак не повлияют друг на друга.

Кроме изначальных затрат на построение ПРАВИЛЬНОЙ! архитектуры обработки и самого API - ТОЛЬКО ОДНИ ПЛЮСЫ!
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

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

Похожие вопросы