Три вопроса о построении многоплатформенного сервиса?
Доброго времени,
думаю, что многим будет интересно узнать ответы. исходные данные: пользователю предоставляется некая функциональность на разных платформах, т.е. есть сайт, есть desktop-приложение, есть мобильное приложение. Ну например, банально: TODO list. Где-то функциональность дублируется, т.е. добавить себе в расписание задачку можно с телефона, или на сайт зайти, или же с desktop-версии. Какие-то фичи есть только на одной платформе. Понятно, что раз данные должны сливаться в одно место, синхронизироваться, за всем этим стоит сервер с rest API.
Что я делаю: беру ASP.net 5 (ну т.е. Core 1), делаю там сайт на MVC 6, кладу это все в Azure. Мобилку наверно на Cordova напишу, desktop - на WPF.
Вопрос #1: надо ли WebAPI (который будут дергать все платформы, в т.ч. сайт) делать отдельным проектом? Почему нельзя просто в этом же MVC сайте сделать для rest-вызовов парочку отдельных контроллеров, которые будут отдавать json?
Вопрос #2: как сделать единую авторизацию? Я понимаю, как работает rest, и что обычно юзаются токены, не хочу нагородить велосипед, наверняка в ASP.net все это как-то из коробки работает, т.е. человек регается на сайте,
запрос к WebAPI (если это отдельный проект) - видимо, берем токен из текущего авторизованного юзера.
запрос с Desktop - один раз спрашиваем логин и пароль, отсылаем на WebAPI, получаем токен и храним его на компе? (вот это все велосипедить?)
ну и мобилка видимо также. Как это все сделать из коробки, красиво?
Вопрос #3: по расписанию надо отправлять почту. Правильно ли я понимаю, что в Azure настраивается schedule, который дергает некий rest в моем WebAPI (кстати, какой? post?), а он шлет почту? Там тоже с авторизацией вопрос, Azure дает выбрать либо сертификат клиента, либо логин/пароль задать.
Ответы на все три вопроса зависят от вашего подхода к разработке и культуры кода. На правах советов:
#1 Наличие отдельного бэкенда даёт больше возможностей масштабирования, и меньшею связанность. Но зачем тогда серверсайд для сайта? Отдельные методы под json — это двойная работа, которая и так уже сделана в WebAPI.
#2 Как корпоративный программист я не силён в человеческой авторизации, но то, что вы описываете и так похоже на современный метод работы с токенами: посмотрите в сторону refresh token.
#3 Это будет авторизация вашей внутри инфраструктуры, так что делайте как удобно. Метод этот — явно не CRUD, можно сконфигурировать отдельный роут для подобных запросов.
#1 Например, складируемые на сервере (который WebAPI) данные нужно как-то обработать, сгенерить по ним отчет, или график. Чтобы не писать этот код дважды, хочу сделать это только в WebAPI, а сайт будет это как-то дергать
#2 Я вот тоже только с Enterprise работал всегда (чаще WCF + WPF, поэтому тут уже поплыл), поэтому и вопрос возник.
#3 Понимаю, что не CRUD, но ведь идеология rest подразумевает, что все есть ресурс. И даже действие - это тоже URI. Вот я и задумался, какой у вызова методов (т.е. действий) эквивалент в rest API.
#1 Зависит от нагрузки, как ниже написал Сергей — если проект несложный, быстрый или вам не нужна гибкость вёрстки, то действительно можно совместить MVC и WebAPI.
#2 Мне кажется, вы думаете в правильном направлении.
#3 Это не строгие правила, а рекомендации. Главное — будьте адекватны ситуации, не опускайтесь до того, чтобы везде использовать один GET. Но в качестве мыслительного эксперимента могу предложить следующие варианты:
Если исходить из того, что REST ориентирован на ресурсы, то действие не попадает в парадигму, и можно ей не следовать, а поступить по моему совету выше.
Интерпретировать действие как команду и воспользоваться POST. Такой подход используется в CQRS, но обычно всё же применяется к реальным ресурсам.
Можно написать свой HTTP метод и его обработку — это странно, практически никогда не используется, но легально.
Кирилл Таран: но у этого роута ведь будет тот или иной тип HTTP-запроса? В принципе, можно ведь интерпретировать отправку писем по расписанию как некий пул заданий, и тогда через PUT туда планировщик добавляет заказ "разошли письма". Там только с аутентификацией я пока не понял, как из под Azure прокинуть туда токен.
TimeCoder: Это как второй вариант из тех, что выше. Самый простой, думаю. Азуровский планировщик я не пробовал, но предполагаю, можно сделать джоб из двух запросов: получить токен первым и добавить во второй как хэдер.
Делать WebAPI отдельным приложением имеет смысл если планируешь ОГРОМНУЮ нагрузку и будешь его запускать на отдельном инстансе. Пока я бы делал одним приложением.
Если использовать asp net identity то в едином приложении MVC+WebAPI проблем нет, для остального придется "ручками" получать токен и передавать его в каждом запросе.
Для отправки почты лучше использовать WebJob. Но тут не совсем понятно зачем тебе аутентификация ты от кого кому письма слать собираешься?
Я просто еще не сталкивался с аутентификацией в Azure, не знаю как это работает. Если есть WebAPI, все его контроллеры требуют авторизации (видимо, через токен), и один из них - отправка почты. Пока не понимаю, что это, просто POST, обращение по которому приводит к отправке писем? Ну вот там може токен, а в Azure при создании расписания нет такой опции, там только логин+пароль. Рассылать письма должен сервер. Ну, грубо говоря, каждое утро все подписчики получают по письму. Вся логика в том самом WebAPI, у него есть список адресов, он крутится в Azure, там же есть, как я понял, система рассылки почты, и там же планировщик.
TimeCoder: Я бы не стал отправлять письма с использованием WebAPI, а просто завел WebJob, который запускается по расписанию, получает из базы список адресов и отправляет по ним письма никакой аутентификации и авторизации получателя не нужно, для отправки письма тебе нужен просто логин и пароль на почтовом сервисе хоть на gmail (1000 писем в сутки можно отправить).
Сергей: дело в том, что письма ведь как-то нужно сформировать, т.е. у них не фиксированный текст, есть общий шаблон, но в него вписываются данные, индивидуальные для пользователя. Если WebJob принимает на вход список адресов и текст письма, то этого недостаточно..
Юрий: не сомневаюсь, что это интересно, только рассказ (судя по первым 10 минутам) слишком проекто-специфичен, это же не туториал по asp.net WebAPI, а рассказ про конкретный проект. Для меня, увы, 2 часа - это роскошь, ищу более конкретные и концентрированные ответы.
Простой
