Возврат результата в приемлемой для пользователя форме?
В моем API должна осуществляться отправка писем, содержащих уникальные ссылки.
Появилась проблема с тем, на какой адрес генерировать ссылку. Скажем, если пользователь введет свою почту в форме iOS клиента, то она пошлется на сервер, произведется валидация, проверка на наличие пользователя с таким адресом и прочее, а потом, если все успешно, на клиенте произойдет перенаправление на уведомительную страницу, свидетельствующую о том, что вот-вот ему придет сообщение с инструкциями на почту и он должен на него отреагировать.
Так вот на моменте, когда сервер зафиксирует, что отправить сообщение можно, нужно сгенерировать адрес, проверяющий пришедший uidb и токен, а если генерить ссылку для адреса внутри DRF проекта, то пользователь, перейдя по ней, увидит результат в формате REST.
Остановился на выводе, что лучше всего направлять пользователя на веб-клиент, обращающийся к этому API и там уже передавать данные обратно к API. Но после моего вопроса, касающегося того, где можно забиндить этот адрес с фронтендом мне сказали, что знать наверняка нельзя и это будет неправильно. Но как же все таки тогда все это производить?
Ничего не понял. Если генерируется уникальная ссылка, значит по этой ссылке юзер должен что-то увидеть, как минимум "До свидания и спасибо за рыбу". Так что добавляем в пути что-то вроде "/дляемейлов", там в обычной вьюшке (не @api_view) достаем параметры из запроса, обрабатываем (например пишем в базу "емейл подтвержден") и показываем страницу-заглушку. В чем проблема?
мне кажется, что это решение в лоб. Я ничего против вашего ответа не имею, просто в силу своего незнания хочу поинтересоваться, нормальна ли эта практика? Меня смущает то, что вьюшка, обрабатывающая этот момент будет находиться внутри проекта API.
Michaebuff, если прямо так хочется, всегда можно сделать отдельный проект, который будет обрабатывать эти ссылки. С точки зрения идеологии микросервисов, конечно, иметь два сервиса, которые пишут в одну базу это моветон, но кто бы ещё соблюдал эту идеологию :). Как наладить в таком случае роутинг (на одном домене) это уже надо будет смотреть отдельно. На разных доменах это будет работать совершенно тривиально.
Владимир, нет-нет, Вы меня не поняли. Я не использую сервисную архитектуру в этом проекте. Это просто проект DRF с API. В нем одном помещена вся логика, я не делил на сервис аутентификации и прочие сервисы. Мне в итоге один человек посоветовал засунуть все в один Django проект, сделать приложение под API и под клиент на вебе. Сказал, что такой подход для монолита норм. И тогда, если я буду генерировать ссылку, то буду уже наверняка знать по какому адресу находится обработчик приходящих uidb и токена.
Простой
