Postman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?
Но если вы большую часть дня проводите в IDE, у этого подхода есть один постоянный friction point: нужно переключаться. Открыть Postman, вспомнить, где нужный запрос, скопировать токен из консоли, вставить руками. Потом вернуться обратно. И так по кругу.
С Amplicode и OpenIDE такой проблемы нет — там есть Connekt, HTTP-клиент на Kotlin DSL, который доступен прямо в IDE. Про него уже немало сказано, даже ребята из Домклик его распробовали и рассказали, как используют. Эта статья — краткий возврат к тому, как и зачем были добавлены те или иные возможности.
Этот клиент позволяет, не переключаясь из среды разработки и сохраняя «кодовое» мышление, писать запросы и выполнять даже целые сценарии с маппингами, DTO и перекладыванием результатов — всё это с помощью Kotlin DSL. Основные возможности можно посмотреть в следующем видео:
Подход показал себя хорошо: как только осваиваешь основные ключевые методы, начинаешь писать всё необходимое для тестирования и выполнения запросов уже на автомате.
Но хотелось бы иметь возможность не проверять данные глазами, а выполнять проверки — как в тестах, автоматически. И сразу видеть все выполненные и упавшие запросы. Ведь можно запускать целиком все свои запросы или даже сценарии в рамках одного ConneKt-файла.
Об этом и о связанной предметной области сегодня и пойдёт речь.
Kotlin DSL
Итак, обо всём по порядку. Начнём с Kotlin DSL.
Kotlin DSL — это подход к написанию конфигураций, а также технической и бизнес-логики, при котором они описываются как декларативный, типобезопасный Kotlin-код, максимально приближенный по стилю к естественному «языку предметной области».
Для разработчика это означает работу не со строковыми ключами и структурами (как в JSON или XML), а с полноценными объектами, функциями и лямбдами с ресивером (Type.() -> Unit), где контекст задаётся через this.
DSL строится на extension-функциях, builder-паттерне и scoped-блоках (apply, with, run), что позволяет писать вложенные конструкции без лишнего шума. Такой формат даёт строгую типизацию, автодополнение и безопасный рефакторинг, а сам код выглядит как конфигурация: компактный, читаемый и иерархически структурированный.
По сути, разработчик создаёт и использует внутренний язык, который компилируется в обычный Kotlin, но воспринимается как декларативное описание системы.
В целом, DSL (domain-specific language) — это подход, при котором язык создаётся под конкретную задачу, будь то SQL, RegExp или, например, Gradle-скрипты .
Моя цель в этой статье — не показать все его возможности, а скорее дать общее представление и продемонстрировать, насколько он удобен.
Для первого знакомства с темой я предлагаю прочитать эти две статьи:
Для тех, кто поленится открывать ссылки, я всё-таки приведу короткий пример.
class Server { var host: String = "localhost" var port: Int = 8080 private val routes = mutableListOf<String>() fun routing(block: Routing.() -> Unit) { val routing = Routing().apply(block) routes.addAll(routing.build()) } fun start() { println("Server started at $host:$port") routes.forEach(::println) } }
class Routing { private val routes = mutableListOf<String>() fun get(path: String) { routes += "GET $path" } fun post(path: String) { routes += "POST $path" } fun build(): List<String> = routes }
Для DSL-функций сделаем отдельный файл, например ServerDsl.kt
fun server(block: Server.() -> Unit): Server = Server().apply(block)
Также вынесем в отдельный файл метод main.
fun main() { server { host = "127.0.0.1" port = 9090 routing { get("/users") post("/users") } }.start() }
Здесь Server и Routing выступают как модель предметной области, а функция server, вынесенная в отдельный DSL-файл, задаёт уже сам язык конфигурации. За счёт этого код выглядит не как набор служебных вызовов, а как декларативное описание сервера и его маршрутов с последующим вызовом.
На этом, думаю, достаточно — мы здесь не ради подробного разбора Kotlin DSL.
Connekt
Выглядит удобно, понятно и мощно, правда? Мы подумали так же, когда решали проблему работы с HTTP-клиентами.
Главная беда большинства HTTP-клиентов в том, что они заставляют переключать внимание и отвлекаться от среды разработки и самого инженерного процесса вокруг задачи, которую кодишь. Кроме того, часто от тебя ожидается, что ты «серьёзно» знаешь ещё какой-то язык и владеешь отдельным инструментарием, чтобы всё это связать воедино. При этом среда разработки никак не помогает понять, как работает внешний HTTP-клиент и связанный с ним код.
Иногда HTTP-клиенты встраиваются в IDE в виде плагинов. Но такие решения в большинстве случаев плохо подходят для реальной работы, особенно если речь идёт о многошаговых сценариях. Они просто принимают настройки и выводят результат в консоль.
Но наша работа устроена иначе. Нам нужен инструмент, который:
живёт прямо в среде разработки,
позволяет выполнять целые сценарии запросов,
даёт возможность удобно перекладывать данные между запросами и ответами в объектном виде.
Чёрт возьми, мы разработчики. Мы хотим писать код, тестировать код кодом и выполнять сценарии запросов без ручного копирования данных и без необходимости каждый раз поднимать отдельное «вспомогательное» приложение.
Так появился Connekt — HTTP-клиент от Amplicode, встроенный в OpenIDE и который вы можете установить отдельно в любую другую IDE на базе JetBrains. Гибкий, с огромным количеством возможностей: он позволяет работать с системами авторизации и аутентификации, сертификатами, перекладывать данные между запросами и выполнять полноценные тестовые сценарии. И самое главное — всё это уже внутри IDE. Достаточно просто положить файлы в директорию проекта, добавить плейсхолдеры — и ими сможет пользоваться вся команда. Он был крут. Как самурайский меч в фильме «Убить Билла». Ультимативный инструмент. Будь такой у крутого Сэма из одноимённой игры — можно было бы играть без мышки.
Самые простые запросы выглядят максимально понятно и тривиально:
Но есть возможность строить и сложные цепочки:
Но главное — это «кодовый» HTTP-клиент, который позволяет пользоваться подсказками среды разработки, автодополнением и привычными конструкциями, не требуя знания отдельного языка.
Более того, учитывая то, что всё больше кода сейчас пишут именно агенты, а не люди, Connekt становится ещё более интересным инструментом. Skills заточенные под Connekt уже доступны на GitHub и их можно использовать с Claude Code, Codex, OpenCode и любым другим популярным агентом.
Да, вы используете Kotlin DSL. И при этом вам вовсе не обязательно быть Kotlin-разработчиком или глубоко знать язык, хотя с некоторыми базовыми вещами познакомиться всё же придётся. Но не стоит относиться к этому настороженно: ничего сверхъестественного не потребуется. Все знания — типовые и во многом универсальные: похожие концепции есть в большинстве языков программирования. Здесь не нужны «семь пядей во лбу» — вы просто играете по понятным правилам.
И всё было отлично. Мы показали клиент широкой аудитории — и получили положительный отклик. Даже Роман Елизаров, автор coroutines в Kotlin, высоко оценил инструмент и отзывался о нём с большим энтузиазмом. Про это даже целое видео есть.
Но хотелось не только удобно перекладывать данные, но и проверять значения в ответах. Поэтому мы занялись поиском подходящего решения.
Поскольку наш HTTP-клиент изначально живёт в Java/Kotlin-ландшафте, вариантов было много, и мнения разделялись. Однако в одном мы сошлись: всё необходимое должно быть «из коробки». Пользователь не должен думать о том, как подключать те или иные библиотеки для проверок. Наша цель была — не отвлекать его от написания сценариев и не заставлять разбираться в сторонних инструментах и их особенностях.
Мы попробовали разные библиотеки. Даже Rest Assured — с его богатым инструментарием — но столкнулись с техническими нюансами, например с подстановкой служебных заголовков.
В какой-то момент стало понятно: нам не хватает «просто проверок ответов» — без лишней сложности, но с красивым и гибким API.
В итоге мы остановились на AssertJ и Kotlin Power Assert. О них и поговорим далее.
AssertJ
AssertJ — это библиотека для тестирования, которая делает проверки понятными и читаемыми. Вместо сухого assertEquals ты пишешь что-то вроде assertThat(user.age).isGreaterThan(18), и это буквально читается как фраза.
За счёт этого проверки становятся не просто проверками, а чем-то вроде документации — по ним сразу видно, что именно ты ожидаешь от кода. Главный плюс AssertJ — удобство и ясность. Библиотека умеет красиво проверять списки, строки, исключения и даже целые объекты без необходимости писать кучу ручных сравнений.
Если тест падает, ты получаешь нормальное, понятное сообщение: что ожидалось и что пришло на самом деле. В итоге меньше времени уходит на разбор, а сами тесты выглядят аккуратно и структурированно.
Однако этого не всегда достаточно. Мы всё-таки пишем в Kotlin-like стиле, где ценятся стильные-модные-молодежные смузи результаты проверок, в которых сразу видно, что именно и где не сошлось.
Не могу не похвастать тем, что в нашем http-клиенте можно писать удобные проверки, которые выглядят клево.
Однако, возможно пользователю не хотелось бы тащить дополнительные импорты в скрипты своих http-запросов. А подключение AssertJ этого требует. Так что мы оставили этот вариант доступным, но предоставили возможность пользоваться сравнениями из стандартной Kotlin-библиотеки.
Kotlin Power Assert
Раз уж речь зашла про Kotlin и его стандартные средства сравнения, грех не использовать все удобства по максимуму. Тем более что это совсем несложно. При этом мы не ожидаем, что наш пользователь обязательно является Kotlin-разработчиком.
Kotlin Power Assert — это плагин, который делает обычные assert гораздо умнее и понятнее. Когда проверка падает, он не просто сообщает «false», а показывает, что именно внутри выражения пошло не так. Например, при сравнении значений он прямо в сообщении об ошибке выводит их реальные значения — и причина становится очевидной без дебага и лишних логов.
Это особенно удобно для простых проверок и формул, где важно быстро понять, какое условие не выполнилось. При этом Power Assert — не замена полноценным библиотекам вроде AssertJ, а скорее приятное дополнение, которое делает результаты сравнений более наглядными.
Согласитесь, это выглядит более кратко с точки зрения кода.
А еще это добавляет наглядности результатам проверок.
Вот это уже прям красиво. В консоли буквально раскладывается по полочкам, что и где не сходится, а вынесение промежуточных значений в переменные добавляет коду аккуратности.
При этом можно задать собственное сообщение для падающей проверки, а сами скрипты — спокойно дебажить.
Как вам такое, любители Postman? Всё ещё копируете значения руками между запросами?
На самом деле все это шутки и ирония. У любого инструмента есть своя аудитория и безусловно Postman бывает хорош в ситуациях, когда у тебя под рукой нет среды разработки.
Но это ещё не всё. Я могу сразу получать DTO, выстраивать цепочки запросов и затем выполнять проверки. И даже при работе с объектами вывод остаётся наглядным и понятным.
Всем этим могуществом можно пользоваться уже сейчас. А главное, это бесплатно. Connekt доступен в бесплатной версии Amplicode.
Еще немного о Connekt и о грядущем
Однако мы пошли дальше и решили, что классно было бы проверять целые сценарии так, чтобы это было удобно. Далее я показываю возможности, которые еще недоступны на момент выхода статьи и станут доступны в грядущем релизе. Если вы хотите попробовать их уже сейчас, то напишите мне в личку :)
В такие моменты видна вся красота Kotlin Power Assert. Он отлично работает для точечных проверок, когда важно понять, что именно пошло не так внутри конкретного выражения. Но в реальных сценариях этого часто недостаточно: хочется выполнить сразу несколько проверок, увидеть результат по всем из них сразу, а не падать при первой же проблеме сверки. Здесь на помощь приходят soft assertions — подход, при котором проверки накапливаются и выполняются вместе, формируя итоговый отчёт со всеми несоответствиями. Это даёт сильный эффект: вы получаете и наглядную детализацию каждой проверки, и полный контроль над сценарием целиком.
Все гениальное просто! Сейчас в моем сценарии два запроса и две проверки. А может быть 10 и я всегда увижу все результаты.
Но, у Kotlin Power Assert есть еще несколько клевых методов в API. Мы провели массу тестов и проверок для выявления сценариев, в которых пользуются Http-клиентами и это позволило нам подумать о читаемости кода и поддержать те, которые оказались уместны в рамках Http-клиента.
Так вместе с soft assertions в Connekt появились require и check. Мне кажется, все это дает огромный прирост надежности в борьбе с багами и проверках API. Ведь, это почти полноценные тесты. Представляете какая возможность автоматизации тестирования появляется, если добавить такие скрипты к автотестам для вашего тестового окружения! - Закачаешься! А ведь все эти вещи не надо писать руками. Amplicode умеет генерировать их для ваших Rest-контроллеров. Пара кликов и целая стена тестовых сценариев, позволяющая провалидировать написанный код и защитить его от багов. Пушка!
Я бы с удовольствием «блеснул шпагой» и показал ещё несколько классных трюков с использованием Connekt, которые появятся в ближайшем будущем, но цель этой статьи — продемонстрировать именно проверки и их силу, поэтому остальное оставлю на десерт.
Заключение
Для полноценной среды разработки необыкновенно важно иметь свой полноценный http-клиент. В разных IDE представлены разные варианты, мы в OpenIDE пользуемся Connekt. На мой взгляд - это лучший из имеющихся http-клиентов и точно самый функциональный и гибкий. Он позволяет не переключаться из среды разработки и не обрывать нить мышления. Про Connekt можно разговаривать много, но лучше один раз попробовать, чем 100 раз увидеть. Пользуйтесь удобным, модным и молодежным тулингом. А еще присылайте нам свои интересные кейсы и спользования. На этом у меня все. Благодарю за внимание.
Актуальные новости о продукте проще всего получать, подписавшись на наш телеграм канал. Получить актуальную версию Amplicode можно на нашем сайте.
