Краткий поиск практически не дал результата. Для таких супер-популярных тем как электронная почта и IMAP на гитхабе нашелся разве что httpmail (10 звезд, 15 лет назад). Другие проекты либо архивированные, либо еще меньше звезд.
Мне кажется это очень странным.... Вебмейлы - популярны: roundcube/rainloop (по 4-5k звезд). Но каждый вебмейл (в нашу эпоху опенсорса и стандартов) идет со своим бэкендом (зачем именно свой-то?). Причем каждый вебмейл как сендвич зачем-то состоит из двух половинок, каждая с разными технологиями, требует разные скиллы от программиста и имеет зачем-то требования к системе. Будто бы, если мне нравится интерфейс RoundCube, я обязан ставить PHP и MySQL (я знаю, что там много вариантов) и PHP на системе.
Насколько я понимаю, напрямую из браузера залезть на IMAP сервер нельзя, нужна "прокладка".
Мне кажется, в идеальном мире, есть протокол IMAP, есть некий (может даже унифицированный) REST интерфейс к нему (вот эта прокладка), и далее вебмейлы пишут фронт-енд программисты, все на JS и fetch(). Весь вебмейл может состоять хоть даже из одного HTML с JS внутри в экстремальном случае и может хоститься статически.
Почему это не так? Я что-то упускаю, есть какой-то фактор, по которому REST API для IMAP - сложная задача или не очень безопасная?
Ответ на самом деле очень прост: этого нет, потому что не особо-то и нужно. Сейчас и почта не слишком активно используется, все в мессенджеры переселяются, даже бизнес-контакты.
Как верно выше сказали вы путаете протокол и сервисы/серверы.
IMAP - это протокол(прикладного уровня, почитайте про модель OSI), те некое соглашение чтобы всё по сети работало одинаково везде и всегда.
REST API - это совсем другое, работает внутри другого протокола HTTP.
Поэтому вам нужно искать не API к IMAP, а сервер IMAP в котором есть нужные API. Такие есть, гуглить нечто вроде
"imap server with rest api"
И там уже сами разработчики серверов реализовывают разные штуки, от управление аккаунтами, до манипуляция с самыми почтовыми ящиками и почтой.
Зачем? Я точно не хочу imap server с лишнием функционалом. Я за unix-way (и этот вопрос ведь как раз про эту идеологию). IMAP сервер уже есть - dovecot. Хороший, вполне устраивает. (но если кого не устраивает - можно заменить на любой другой, который удобнее, по вкусу). Зачем повторно реализовывать IMAP сервер в другом проекте?
То, что я имею в виду, это, можно сказать, серверная половинка от любого вебмейла. Получает запросы через вебсервер, обрабатывает их по IMAP протоколу и возвращает ответ.
Ярослав, эмм. а в чем здесь не юникс вей?
У dovecot кстати есть HTTP API. dovecot кстати та ещё фигня в контексте юниксвея в некоторых моментах, хотя в целом мне нравится тоже пользуюсь.
А вам все же советую вспомнить или подучить, что такое протоклы и тп.
Вы поймите, сам браузер работает по HTTP протоколу, IMAP будет поддерживать если есть плагин для него.
Если вы хотите REST API - те запросы по HTTP к IMAP, то естественно нужна прослойка или IMAP сервер где уже эта прослойка реализована.
Ну а остальное вы сами в своем комментарии написали. Значит ваш поиск будет на веб морде, может быть даже типа хедлесс(headless без фронта, но с API) к почтовым сервисам на сервере.
Меньше философии, больше логики. Это кстати про юникс вей ;-)
Потому что IMAP - это сам себе протокол.
Каждый почтовый сервис может для себя придумать какой-нибудь свой REST API, но все эти варианты не стандартизированы.
Из стандартизированных есть jmap, но мало кто его использует.
Есть стандарты RFC 8620, RFC 8621RFC 8887 (JMAP), фактически на REST API для почты и того что рядом с ней, если поищите - есть библиотеки этот стандарт реализующие, например сервер и клиент на Rust.
По факту, это стандартизованный FastMail'ом его API, другим вебпочтам переезжать со своего давно написанного и отлаженного API на FastMail'овский причин нет, т.к. это означает что придется переписывать не только серверную, но и клиентскую часть, причем при наличии мобильных приложений использующих API какое-то время поддерживать две версии API, потому что пересадить клиентов на новый API одномоментно невозможно, а преимуществ, по крайней мере прямо сейчас нет - "универсальные" клиенты используют IMAP.
Есть и другие документированые (но не стандартизованные) API, например у Google.
Блин, Ярославище, ну ты даешь. IMAP - это протокол, по которому работают. Используя этот протокол, можно получать почту, читать ее и все такое. rest api для IMAP - это совершенно второстепенная финтифлюшка.
Ну и кроме того - обратил внимание, что почтовых клиентов, как независимвх приложений - сейчас полторы калеки? Outlook и Thunderbird, что ужаснее - еще трудно сказать. Ну крыса еще, если жива. Все учапали в веб-морды, поголовно.
CommuniGate нам тут рекламировали - дык для того, чтобы его посмотреть, хотя бы клиента - нужно сервер разворачивать, потому что по IMAP он как раз нихрена не работает.
> IMAP - это протокол, по которому работают
Дааа ну? Может еще и HTTP это не программа? :-))
Но мне вот эта второстепенная сейчас и захотелась. Чтобы вебморда сама могла почту забирать, без еще одного велосипеда (а то их же так мало!). Раз напрямую к серверу из браузера коннектиться нельзя, то пусть через какой-нибудь унифицированный REST API.
Увидился, что ее нет. В каждом вебмейле - свой велосипед зачем-то. Пока что вот мысль про JMAP самая интересная и даже готовые реализации есть. И вебморды JMAP-овские тоже есть.
Простой
Простой
Простой
Средний
Средний
Простой
