Какую выбрать архитектуру взаимодействия мобильных приложений и веб-версии с API?

Question

[Виктор Гуров]

Доброго всем дня. Возник вопрос, касающийся архитектуры взаимодействия мобильных приложений и веб-версии с API. Подскажите лучшее решение. Суть:

Есть backend приложение с API. С этим интерфейсом могут общаться различные мобильные приложения, записи о которых хранятся в БД на сервере. Каждое такое приложение имеет свой токен, при помощи которого API знает, кто обращается (и, соответственно, может определять права и т.п.). Он обязателен для всех endpoint-ов. Данные - общие, привязки к приложениям нет, и, соответственно, любое приложение может редактировать любые сущности (какое конкретно редактировало - указывается). Для редактирования данных во всех случаях необходимо авторизоваться пользователю (то есть помимо токена приложения будет слаться ещё access token).

Помимо мобильных приложений пользователи должны иметь возможность авторизоваться на веб-версии (Angular.js) и оттуда из админки также иметь доступ к функиональности редактирования данных.

Вопрос: каким образом вы бы организовали процесс взаимодействия веб-админки на ангуляре с API при существующей концепции общения внешних источников с сервером?

Текущий вариант: в БД присуствует приложение с токеном, от которого работает angular.js приложение. Является ли такой подход нормальным или взаимодействие собственных frontend с backend должно быть организовано как-то по иному ? Спасибо!

---

1. Я бы не использовал ангуляр в этом случае вообще.
Хватило бы одного jquery.
2. Пишем класс взаимодействия с API, методы (авторизацию, откуда взять(URL) и куда положить (DOM-node) и т.д.)
3. Пишем класс-манипулятор с использованием класса работы с API: взять-положить, заменить отправить и т.д.
4. Используем методы класса-манипулятора для обработки событий объектов (клики по линкам, и т.д.)

Как будет работать frontend с API - это понятно. Ангуляр или jQuery - не суть. Суть вопроса в архитектуре взаимодействия: необходимо ли для веба выделять отдельное приложение или, например, в API определять, что запросы идут с IP сервера, а значит они от нашей админки, и т.п.

Приложение разберут, достанут токен и кто угодно с этим токеном будет обращаться к api.

Токен только для идентификации приложений ("что за оно?"), безопасность обеспечивается авторизацией пользователя.

Answer 1

[xmoonlight]

1. Я бы не использовал ангуляр в этом случае вообще.
Хватило бы одного jquery.
2. Пишем класс взаимодействия с API, методы (авторизацию, откуда взять(URL) и куда положить (DOM-node) и т.д.)
3. Пишем класс-манипулятор с использованием класса работы с API: взять-положить, заменить отправить и т.д.
4. Используем методы класса-манипулятора для обработки событий объектов (клики по линкам, и т.д.)

Answer 2

[xfg]

Текущий вариант: в БД присуствует приложение с токеном, от которого работает angular.js приложение. Является ли такой подход нормальным или взаимодействие собственных frontend с backend должно быть организовано как-то по иному ?

Хранить токен в приложениях, выполняющихся на клиенте бессмысленно. Приложение разберут, достанут токен и кто угодно с этим токеном будет обращаться к api.

Как правило, официальные приложения не ограничивают в правах. Ограничивают приложения от сторонних разработчиков и это делается через протокол OAuth 2.0. Какие права дать стороннему приложению, решает сам пользователь. Токен выдается на пользователя. На само приложение токен имеет смысл выдавать, только если приложение выполняется на стороне сервера, в противном случае, бессмысленно. Более подробно в rfc6749

Я вообще не понимаю, зачем вам требуется выдавать токен на приложение. Ограничить endpoints set для каждого из приложений? Зачем? Что это дает? Опишите задачу.

Comments

[Виктор Гуров]

См. поправки к моему вопросу