Explyt Spring Plugin — наша версия HTTP-клиента для IntelliJ IDEA / Комментарии / Хабр

Мне кажется не стоит изобразить что-то новое, достаточно просто сделать копию плагина, совместимую по dsl. У меня например в каждом проекте .http файлы с данными, заново все переносит куда-то как-то не хочется

grisha9 17 янв в 19:27

Отчасти я могу с вами согласиться, но это все таки немного разные истории. Мы прежде всего Spring плагин и изначально наш клиент “родился” из задачи генерации OpenApi файлов по Spring Controllers. Это в целом достаточно распространенная задача и есть множество её реализаций, а далее прикрутить к этому делу Swagger UI не составило никаких проблем и мы за очень дешево получили полнофункциональный веб клиент с готовым UI, приложив минимум усилий.
А реализовывать полноценную поддержку idea http языка - его парсинг, выполнение, UI для работы с результатами запрсов… это задача совсем другого калибра.

pivozavr228 21 янв в 07:46

То есть, вы не осилили? Или заранее прикинули, что задача не по зубам (другого калибра)?

grisha9 21 янв в 10:46

Давайте еще раз уточним нашу позицию:

Цели и приоритеты
Как я упоминал выше, у нас изначально не стояла задача поддерживать именно *.http формат из IDEA. Мы пришли к идее сделать собственный клиент уже после того, как получили OpenAPI-файлы.
Экономия времени и упор на готовые инструменты
Использование Swagger UI сразу дало нам готовый пользовательский интерфейс, к которому многие уже привыкли. Это экономит массу времени и усилий как в разработке, так и в дальнейшей поддержке — нет необходимости поддерживать собственный DSL или веб-клиент.
Почему не *.http
Чтобы интегрировать *.http-синтаксис, нам потребовалась бы официальная открытая грамматика (BNF) от его авторов. Мы такой не нашли. Конечно, можно было бы написать её самим, но вопрос в том, насколько это оправдано с точки зрения конечного результата: мы получили бы функциональность, очень похожую на уже имеющиеся решения, при этом затратив немало ресурсов на поддержку.
Выбор в пользу простоты
Мы выбрали более простой путь, ориентируясь на проверенные инструменты и формат (OpenAPI + Swagger UI). Это позволило нам быстрее достичь цели и при этом не «изобретать» ещё один стандарт для написания HTTP-запросов.

Надеюсь, так яснее, почему мы приняли именно такое решение.