В предыдущей статье "Как жить без IntelliJ IDEA" мы разбирали, какие есть альтернативы Ultimate в части поддержки Spring.

В этой части команда Spring АйО исследует, чем можно заменить встроенный HTTP-клиент JetBrains, за что его так любят разработчики и какие инструменты могут стать достойной альтернативой.

Ранее мы выяснили, что жить без IntelliJ IDEA Ultimate можно, пока Community версия доступна для скачивания без ограничений. И даже если её скачивание станет невозможным, всегда можно будет собрать Community вручную из открытого исходного кода.

Если спросить у Spring-разработчика за что он любит IntelliJ IDEA Ultimate, то ответ вероятнее всего будет следующим: "Spring поддерживается, SQL-запросы удобно выполнять вот в этой панельке Database справа, а ещё по HTTP можно эндпоинты дёргать прямо из IDE". Про поддержку Spring мы рассказали во второй статьей из цикла, про выполнение SQL-запросов поговорим в следующей, а сегодня разберемся с HTTP-клиентом.

В чём сила HTTP-клиента от JetBrains?

Как всегда, прежде чем рассматривать альтернативы, давайте разберемся, за что разработчикам так полюбился HTTP-клиент от JetBrains.

Если и есть причина, за которую разработчики могут полюбить ту или иную фичу – это понятный и удобный с UX (User eXperience). Другими словами, такие фичи как:

• Генерация запроса прямо из кода. Например, из метода Spring контроллера или из OpenAPI схемы.

• Автодополнения путей в момент набора запроса вручную. Кстати появилось только в версии 2023.1. Так что, если вы сидите на более старой IntelliJ IDEA, эту фичу вы еще не видели.

• Возможность запуска запроса прямо из IDE через хорошо знакомую зеленую стрелочку.

формируют интуитивное понимание простоты и удобства использования инструмента в повседневном flow разработчика.

Также стоит отметить, что выбранный JetBrains понятный текстовый формат описания запросов, сильно похожий на стандарт RFC 7230, также значительно снижает порог входа в использование инструмента. Вам не нужно знать что-то ещё, кроме структуры HTTP-запроса, чтобы выполнить его прямо в IDE.

Не можем не упомянуть поддержку множества протоколов, не только REST, наличие профилей (environment), а также возможность писать небольшие тесты и запускать их на CI.

Отдельно хочется отметить возможность записывать в variables произвольные значения, полученные в том числе через разбор результата выполнения запроса, что позволяет, например, тестировать сценарии, затрагивающие несколько последовательных запросов.

А как вы использовали HTTP Client? Пишите в комментариях!

Плагины для IntelliJ IDEA

Первым делом давайте посмотрим на бесплатные плагины для IntelliJ IDEA. Может, мы сможем найти что-то подходящее и закончить на этом статью? В маркетплейсе есть некоторое количество плагинов, в названии которых есть слово Restful.

RestfulToolkitX

RestfulToolkitX даже встроен в GigaIDE. Должно быть, неплохой плагин. Плагин добавляет новую боковую панельку в IDE, в которой перечислены все доступные эндпоинты нашего Spring приложения.

Каждый из эндпоинтов можно вызвать, и RestfulToolkitX даже генерирует нам шаблон RequestBody, разобрав, какие параметры передаются в метод контроллера. Однако общий UX плагина достаточно плохой. Никакой подсветки синтаксиса для JSON; плагин не запоминает RequestBody, RequestParameters и Headers, которые я указал для данного эндпоинта; в случае ошибки я просто вижу эксепшн; ну и никакой специализированной поддержки для последовательного вызова нескольких запросов. Вызвать произвольный запрос можно, но не самым очевидным образом - нужно просто полностью переписать параметры любого другого, предзаполненного запроса. На самом деле, больше про плагин сказать и нечего. Выполнить запрос он позволяет, но ничего больше. Есть инструменты и поудобней, о чем мы поговорим ниже.

HURL

Вообще HURL это CLI инструмент, который работает с файлами расширения .hurl, который по синтаксису очень похож на .http. Помимо самих запросов, позволяет писать несложные тесты, а также, извлекать данные из ответов, для дальнейшего их использования в последующих запросах. Нас он особенно заинтересовал тем, что для него есть плагин, который также похож на HTTP Client.

Выглядит это все очень интересно, но, к сожалению, плагин очень сырой и его UX очень сильно не дотягивает до JetBrains HTTP Client. Идея с сохранением значений, извлеченных из запросов классная, но реализация - хромает. Эти самые значения, по всей видимости, хранятся в оперативной памяти hurl, и поэтому, их можно использовать только при запуске всего файла целиком, а сделать это средствами плагина не так-то просто: нужно открыть редактор Run Configuration и изменить параметры запуска.

Отсутствует генерация запросов от эндпоинта, отсутствует навигация, нельзя запускать запросы на разных Environment. Ну, как нельзя, на самом деле сам клиент это делать позволяет - можно передать файл с параметрами с помощью аргумента командной строки --variables-file, но плагин вам в этом не поможет. Код плагина открыт, так что доработкой может заняться любой желающий!

Пишите тесты

Прежде чем рассматривать полноценные альтернативы, стоит отметить, что для проверки ответа HTTP-эндпоинта нередко более правильным подходом оказывается написание теста, а не использование отдельного HTTP-клиента. Этот подход имеет несколько преимуществ:

• Тестовые фреймворки или REST-клиенты, как правило, уже включены в зависимости проекта, а разработчики умеют ими пользоваться. Таким образом мы избавляемся от необходимости изучать дополнительные инструменты

• Вместо разового вызова эндпоинта вы создаёте тест, который можно использовать повторно или доработать в будущем, что может положительно сказаться на коде проекта в целом

• Всё выполняется непосредственно в среде разработки, нам не нужно выходить за её пределы (прямо как и с HTTP-клиентом!)

• С каждым новым релизом Spring'а API для тестирования и выполнения запросов становится всё лаконичнее и лаконичнее. Так может проще написать пару строчек кода в .java файле, чем в .http?

Однако есть и ограничения. HTTP-клиенты также используются для взаимодействия с внешними сервисами, для проверки и изучения их поведение. Для таких задач написание тестов обычно не практикуется. Кроме того, в проекте могут быть строгие правила относительно тестирования, и вызов каждого эндпоинта может не соответствовать этим правилам.

В общем, если есть возможность написать тест, то лучше его написать. Мысль тривиальная, но мы не могли её не озвучить.

VS Code

Одним из самых популярных расширений в маркетплейсе VS Code является REST Client. Одним из ключевых его преимуществ в контексте поиска аналога HTTP-клиенту от JetBrains является поддержка .http файлов, которые как раз и использует IntelliJ IDEA. Если у вас уже есть довольно большое количество .http файлов, первое время можно попробовать пожить между двумя IDE. Что, конечно, не очень удобно, но зато формат запросов будет привычным.

Решение далеко от идеала, но подойдет тем разработчикам, которые решили перейти на VS Code. В прошлой статье мы как раз обозревали возможность использования этой IDE для Spring разработки, хотя она очень сильно не дотягивает до IntelliJ IDE.

CLI инструменты

Среди различных CLI-инструментов, упрощающих работу с HTTP-запросами, думаю практически каждый из вас знаком с curl. Это мощный инструмент, который позволяет отправлять HTTP-запросы и получать ответы, будь то простой GET-запрос или сложные сценарии с авторизацией, отправкой файлов и настройками заголовков.

Скептики могут спросить: "Куда еще лучше?". Но давайте всё же рассмотрим некоторые из наиболее интересных решений.

HTTPie – это, пожалуй, самый популярный CLI-инструмент для работы с HTTP, судя по количеству звезд на GitHub. Он предоставляет интуитивно понятный синтаксис, позволяя писать запросы почти как обычные предложения, что делает его особенно удобным для чтения. HTTPie также поддерживает цветовое выделение, обработку аутентификации и обладает гибкими возможностями по обработке JSON и других форматов.

Наверняка мы забыли про ещё какой-нибудь CLI-tool, которым пользуетесь именно вы. Если так – напишите нам про него в комментариях ;)

Все эти тулы, конечно, прекрасны, но в контексте альтернативы HTTP-клиенту встроенному в IDE имеют очевидный недостаток – они не встроены в IDE :D. Нет, мы конечно можем открыть терминал прямо в IDE и выполнить запрос оттуда, но вот сгенерировать запрос отталкиваясь от эндпоинта у нас не получится.

Это что за покемон TUI?

Знаете ли вы, что такое TUI Terminal Tools? Это новый этап в эволюции CLI-инструментов. Всё взаимодействие с инструментом происходит в терминале, но теперь с более приятным интерфейсом. Один из таких инструментов — Posting, HTTP-клиент, который похож на Postman или Insomnia, но работает прямо в терминале. 

Благодаря интерфейсу TUI, его удобно использовать даже через SSH, а рабочие процессы оптимизированы под взаимодействие исключительно через клавиатуру. Запросы сохраняются локально в простых YAML-файлах, что делает их легко читаемыми и удобными для контроля версий. К тому же Posting поддерживает импорт спецификаций OpenAPI.

Postman и КО

В мире разработки и тестирования API существует множество удобных UI-инструментов для выполнения HTTP-запросов. Наиболее популярным и узнаваемым среди них является Postman, но также существует множество достойных альтернатив:

• Insomnia

• Hoppscotch

• Bruno

• Scalar

• Apidog

• HTTPie Desktop — знакомый многим HTTPie, только в удобной оболочке с графическим интерфейсом

Большинство этих инструментов в своей рекламе указывают, что являются “open-source альтернативой Postman”. Другими словами, Postman стал своего рода нарицательным именем для подобных инструментов, однако конкуренты пытаются выделиться за счёт своей открытости и особенностей.

Функциональность большинства из них в целом схожа, но есть моменты, на которые стоит обратить внимание при выборе подходящего решения:

1. Лицензия на использование. Например, Postman частично бесплатен, но некоторые функции доступны только по подписке. Если вы планируете использовать инструмент в долгосрочной перспективе, важно учитывать возможные ограничения и затраты.

2. Open-source и доступность исходного кода. Наличие исходников и лицензии на них — важный аспект для многих команд. С ростом популярности облачных технологий многие open-source проекты пересматривают свои лицензии, поэтому стоит убедиться, что выбранный вами инструмент будет оставаться доступным. Будет ли возможен форк и продолжение его развития в случае изменения лицензии? Ситуации с ElasticSearch, Redis и Terraform показывают, что это не просто теория.

3. Интеграция с OpenAPI. Большинство инструментов поддерживают импорт и экспорт OpenAPI спецификаций. Это удобная функция, которая избавляет от необходимости вручную воссоздавать структуру API. Например, используя Spring, можно легко подключить стартер springdoc-openapi, чтобы генерировать спецификации автоматически.

4. Разворачивание через Docker. В современных проектах часто используют Docker Compose для развертывания локального окружения, включая такие вспомогательные сервисы, как pgAdmin, Kafka UI или Mongo Express. Возможность добавить туда инструмент для тестирования API через Docker значительно упрощает работу. Если добавить автоматический импорт OpenAPI спецификации, которую генерирует бекенд, можно мгновенно получить доступ ко всем эндпоинтам прямо в удобном UI-интерфейсе.

Помимо хорошо известного редактора запросов, Postman имеет отдельный инструмент для визуального программирования. Postman Flows позволяет тестировать достаточно большие сценарии с множеством запросов, которые выполняются последовательно, параллельно, может иметь логику ветвления и даже циклы!

Все это очень занятно, но на наш взгляд, это больше инструмент для команды тестирования, чем для разработки. У нас не получилось выяснить, можно ли запускать Flow на CI. Другим большим минусом является то, что их нельзя положить в git, и соответственно - отслеживать историю изменений. Вообще, то что можно написать с помощью кода, лучше написать с помощью кода.

Пишите скрипты

Летом мы рассказывали вам о магии Markdown файлах в IntelliJ IDEA. Эти файлы могут быть местом для размещения наших curl вызовов, рядом с которыми можно и документацию написать. Помимо этого, мы можем писать скрипты на Kotlin, используя какой-нибудь ktor в качестве самого HTTP клиента. Не будем повторяться и просто дадим ссылку на статью. 

Подход имеет как плюсы так и минусы. Во-первых, скрипты можно дебажить!  Во вторых, отметим невероятную гибкость Kotlin скриптов: можно протестировать практически какой-угодно сценарий. Однако, это же и его минус. Отсутствие хоть какого-то формализма может и, скорее всего, приведет к бардаку. Ну и конечно, отсутствие специализированной поддержки в IDE, а это именно то, что нам так нравится в HTTP Client от JetBrains.

Старый добрый Swagger UI

Если мы хотим вручную проверить работоспособность запроса в нашем Spring Boot приложении, то нам вполне подойдет стартер springdoc-openapi. 

Подключая стартер, мы, во-первых, получаем openapi схему для нашего приложения; во-вторых, возможность вызова эндпоинтов из web ui. Swagger помогает чем может и для каждого запроса генерирует параметры по-умолчанию, хотя и не всегда правильно. Сформированный запрос можно скопировать в виде curl.

Инструмент может быть полезен и для команды QA, которая сможет протестировать запросы на развернутом стенде. Но, честно говоря, скорее они будут использовать упомянутый выше Postman или похожий инструмент.

Кроме того, в swagger-ui нельзя менять произвольные параметры запроса, такие как Headers. Доступны на редактирование будут только те из них, которые явно описаны в документации к запросу.

А как бы выглядел идеальный HTTP Client?

Является ли при всем перечисленном JetBrains HTTP Client пределом мечтаний? Можем ли мы выдумать более крутой инструмент? Хочется взять все лучшее из всех перечисленных выше подходов.

Идеальный HTTP Client должен обладать следующими возможностями:

• Глубокая интеграция с IDE: возможность генерации запросов на основе кода контроллеров, удобная навигация, автодополнение и визуальные элементы интерфейса, такие как зеленая стрелочка для запуска запросов.

• Поддержка тестирования произвольных сценариев, включая сложные последовательности запросов с обработкой и сохранением результатов.

• Возможность запуска на CI/CD: интеграция с процессами непрерывной интеграции для проверки корректности работы API на различных стадиях разработки.

• Лёгкое совместное использование: возможность сохранять запросы в читаемом формате, которые можно положить в git и отслеживать изменения, а также делиться ими с коллегами по проекту.

• Поддержка написания ассертов и обработки результатов с помощью языка, более привычного для Java разработчиков, чем JavaScript, к примеру, с помощью Kotlin.

• Дебаг и пошаговое выполнение.

И, кажется, все это есть в HTTP Client, кроме последних двух пунктов. Ну и конечно доступность в РФ - было бы неплохо. Дождемся ли мы такого инструмента? Кто знает…

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Ждем всех, присоединяйтесь