Установка
Один артефакт в Maven Central, Java 17 и новее, без зависимостей.
Установка
Текущий выпуск: 0.0.1. В нём есть метод для каждого метода TypeScript SDK, и проверка паритета пакета ломает сборку, когда какого-то не хватает или он отправляет другой запрос.
<dependency> <groupId>uk.openemail</groupId> <artifactId>openemail</artifactId> <version>0.0.1</version></dependency>import java.util.Map;import uk.openemail.Body;import uk.openemail.OpenEmail; public final class FirstEmail { public static void main(String[] args) { OpenEmail client = new OpenEmail(); Map<String, Object> email = client.emails().send(Body.of( "from", "Acme Billing <[email protected]>", "to", "[email protected]", "subject", "Your September invoice", "html", "<p>Invoice attached.</p>" )); System.out.println(email.get("id") + " " + email.get("status")); }}new OpenEmail() читает ключ из OPENEMAIL_API_KEY, поэтому в коде нет учётных данных. Используйте OpenEmail.builder().apiKey(...), когда ваша конфигурация хранится в другом месте.
Тело запроса представляет собой Map<String, Object>, ключи которого сохраняют имена API, поэтому scheduledAt пишется здесь так же, как в справочнике API. Body.of создаёт такое тело, сохраняет порядок, в котором вы его записали, и принимает значения null. Ответ представляет собой декодированный JSON в виде Map<String, Object>, поэтому email.get("id") читает идентификатор.
То, что send вернул результат, не значит, что сообщение ушло. Запланированная или отменяемая отправка возвращается со статусом queued или scheduled и завершается позже. Читайте status, а не сам факт возврата из вызова.
Где он работает
Java 17 и новее, на любом языке JVM. У jar нет зависимостей, и он называет свой модуль uk.openemail для приложений на пути модулей.
Клиент неизменяем, и его безопасно использовать из нескольких потоков. Создайте один при запуске приложения и храните его: он держит один HttpClient, который переиспользует свои соединения.
Клиент несёт API-ключ рабочего пространства, который может отправлять почту и читать почтовый ящик, поэтому его место на сервере, в задании или в инструменте, который работает на вашей собственной машине. Храните ключ в переменной окружения или в хранилище секретов, но никогда в коде.