[{"data":1,"prerenderedAt":167},["ShallowReactive",2],{"$fBBQ5ulyG5jVWbIBJe3r8F-kTKQKf1scMJiu0B6qzX5k":3,"$f7AVZHmPutZ23_8XKkLbDtEszKCuiY3yPjIDp9eRXGag":5,"$faOHskI1-UoUPCl8QGKNmDkN2f4o-Goi13_JvsV2fTeI":7,"$fbIoDiL9VNkoktkDSUf9NSv0cHNHNOCxcRGLOp9kcgHo":143},{"data":4},[],{"data":6},[],{"data":8,"meta":139},[9],{"id":10,"documentId":11,"title":12,"seo_title":13,"summary":14,"seo_description":15,"slug":16,"published_date":17,"body":18,"content":19,"createdAt":41,"updatedAt":42,"publishedAt":43,"blogauthor":44,"cover":95,"categories":128},397,"qi6lok15291y1ijghvmmr8da","Как тестировать API прямо в IDE, или почему я больше не использую Postman","Тестирование API в IDE вместо Postman: Connekt","Как тестировать API, не переключаясь из IDE в Postman: HTTP-клиент Connekt на Kotlin DSL и автоматические проверки ответов через AssertJ и Kotlin Power Assert.","Connekt — HTTP-клиент на Kotlin DSL в OpenIDE и Amplicode. Как писать запросы и сценарии и проверять ответы с AssertJ и Kotlin Power Assert прямо в IDE.","kak-testirovat-api-pryamo-v-ide-ili-pochemu-ya-bolshe-ne-ispolzuyu","2026-04-03","![]({{strapiUrl}}\u002Fuploads\u002F764a102842cbc88258f52fc7adeff7d0_8fde458605.webp)\n\nPostman используют миллионы разработчиков — и не зря. Удобный интерфейс, коллекции, окружения, командный доступ. О чём еще мечтать?\n\nНо если вы большую часть дня проводите в IDE, у этого подхода есть один постоянный friction point: нужно переключаться. Открыть Postman, вспомнить, где нужный запрос, скопировать токен из консоли, вставить руками. Потом вернуться обратно. И так по кругу.\n\nС [Amplicode](https:\u002F\u002Famplicode.ru\u002F) и [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) такой проблемы нет — там есть [Connekt](https:\u002F\u002Famplicode.ru\u002Fhttp-client\u002F), HTTP-клиент на Kotlin DSL, который доступен прямо в IDE. Про него уже немало сказано, даже ребята из Домклик его распробовали и [рассказали](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fdomclick\u002Farticles\u002F965116\u002F), как используют. Эта статья — краткий возврат к тому, как и зачем были добавлены те или иные возможности.\n\nЭтот клиент позволяет, не переключаясь из среды разработки и сохраняя «кодовое» мышление, писать запросы и выполнять даже целые сценарии с маппингами, DTO и перекладыванием результатов — всё это с помощью Kotlin DSL. Основные возможности можно посмотреть в следующем видео:\n\n\u003Cdiv class=\"video-player\" data-youtube=\"TXUyoVP9CpA\" data-vk=\"-230816739_456239021\" data-rutube=\"ec3354160046501e9a970648d73caefd\" data-rutube-key=\"5y_t1rK0be5q_2gFu0g6Vg\">\u003Ciframe src=\"https:\u002F\u002Fwww.youtube.com\u002Fembed\u002FTXUyoVP9CpA\" width=\"100%\" height=\"400\" frameborder=\"0\" allowfullscreen loading=\"lazy\">\u003C\u002Fiframe>\u003C\u002Fdiv>\n\nПодход показал себя хорошо: как только осваиваешь основные ключевые методы, начинаешь писать всё необходимое для тестирования и выполнения запросов уже на автомате.\n\nНо хотелось бы иметь возможность не проверять данные глазами, а выполнять проверки — как в тестах, автоматически. И сразу видеть все выполненные и упавшие запросы. Ведь можно запускать целиком все свои запросы или даже сценарии в рамках одного ConneKt-файла.\n\nОб этом и о связанной предметной области сегодня и пойдёт речь.\n\n\u003Ch2 id=\"kotlin-dsl\">Kotlin DSL\u003C\u002Fh2>\n\nИтак, обо всём по порядку. Начнём с Kotlin DSL.\n\nKotlin DSL — это подход к написанию конфигураций, а также технической и бизнес-логики, при котором они описываются как декларативный, типобезопасный Kotlin-код, максимально приближенный по стилю к естественному «языку предметной области».\n\nДля разработчика это означает работу не со строковыми ключами и структурами (как в JSON или XML), а с полноценными объектами, функциями и лямбдами с ресивером (Type.() -> Unit), где контекст задаётся через this.\n\nDSL строится на extension-функциях, builder-паттерне и scoped-блоках (apply, with, run), что позволяет писать вложенные конструкции без лишнего шума. Такой формат даёт строгую типизацию, автодополнение и безопасный рефакторинг, а сам код выглядит как конфигурация: компактный, читаемый и иерархически структурированный.\n\nПо сути, разработчик создаёт и использует внутренний язык, который компилируется в обычный Kotlin, но воспринимается как декларативное описание системы.\n\nВ целом, DSL (domain-specific language) — это подход, при котором язык создаётся под конкретную задачу, будь то SQL, RegExp или, например, Gradle-скрипты .\n\nМоя цель в этой статье — не показать все его возможности, а скорее дать общее представление и продемонстрировать, насколько он удобен.\n\nДля первого знакомства с темой я предлагаю прочитать эти две статьи:\n\n[Основы DSL в KotlinАвтор статьи: Сергей Прощаев ( @sproshchaev ) Руководитель направления Java-разработки в FinTech Вве...habr.com](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fotus\u002Farticles\u002F967488\u002F)[Kotlin DSL: Теория и ПрактикаSql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных язы...habr.com](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fhaulmont\u002Farticles\u002F341402\u002F)\n\nДля тех, кто поленится открывать ссылки, я всё-таки приведу короткий пример.\n\n```kotlin\nclass Server {\n    var host: String = \"localhost\"\n    var port: Int = 8080\n\n    private val routes = mutableListOf\u003CString>()\n\n    fun routing(block: Routing.() -> Unit) {\n        val routing = Routing().apply(block)\n        routes.addAll(routing.build())\n    }\n\n    fun start() {\n        println(\"Server started at $host:$port\")\n        routes.forEach(::println)\n    }\n}\n```\n\n```kotlin\nclass Routing {\n    private val routes = mutableListOf\u003CString>()\n\n    fun get(path: String) {\n        routes += \"GET $path\"\n    }\n\n    fun post(path: String) {\n        routes += \"POST $path\"\n    }\n\n    fun build(): List\u003CString> = routes\n}\n```\n\nДля DSL-функций сделаем отдельный файл, например ServerDsl.kt\n\n```kotlin\nfun server(block: Server.() -> Unit): Server =\n    Server().apply(block)\n```\n\nТакже вынесем в отдельный файл метод main.\n\n```kotlin\nfun main() {\n    server {\n        host = \"127.0.0.1\"\n        port = 9090\n\n        routing {\n            get(\"\u002Fusers\")\n            post(\"\u002Fusers\")\n        }\n    }.start()\n}\n```\n\nЗдесь `Server` и `Routing` выступают как модель предметной области, а функция `server`, вынесенная в отдельный DSL-файл, задаёт уже сам язык конфигурации. За счёт этого код выглядит не как набор служебных вызовов, а как декларативное описание сервера и его маршрутов с последующим вызовом.\n\nНа этом, думаю, достаточно — мы здесь не ради подробного разбора Kotlin DSL.\n\n\u003Ch2 id=\"connekt\">Connekt\u003C\u002Fh2>\n\nВыглядит удобно, понятно и мощно, правда? Мы подумали так же, когда решали проблему работы с HTTP-клиентами.\n\nГлавная беда большинства HTTP-клиентов в том, что они заставляют переключать внимание и отвлекаться от среды разработки и самого инженерного процесса вокруг задачи, которую кодишь. Кроме того, часто от тебя ожидается, что ты «серьёзно» знаешь ещё какой-то язык и владеешь отдельным инструментарием, чтобы всё это связать воедино. При этом среда разработки никак не помогает понять, как работает внешний HTTP-клиент и связанный с ним код.\n\nИногда HTTP-клиенты встраиваются в IDE в виде плагинов. Но такие решения в большинстве случаев плохо подходят для реальной работы, особенно если речь идёт о многошаговых сценариях. Они просто принимают настройки и выводят результат в консоль.\n\nНо наша работа устроена иначе. Нам нужен инструмент, который:\n\n- живёт прямо в среде разработки,\n- позволяет выполнять целые сценарии запросов,\n- даёт возможность удобно перекладывать данные между запросами и ответами в объектном виде.\n\nЧёрт возьми, мы разработчики. Мы хотим писать код, тестировать код кодом и выполнять сценарии запросов без ручного копирования данных и без необходимости каждый раз поднимать отдельное «вспомогательное» приложение.\n\nТак появился [Connekt](https:\u002F\u002Famplicode.ru\u002Fhttp-client\u002F) — HTTP-клиент от [Amplicode](https:\u002F\u002Famplicode.ru\u002F), встроенный в [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) и который вы можете установить отдельно в любую другую IDE на базе JetBrains. Гибкий, с огромным количеством возможностей: он позволяет работать с системами авторизации и аутентификации, сертификатами, перекладывать данные между запросами и выполнять полноценные тестовые сценарии. И самое главное — всё это уже внутри IDE. Достаточно просто положить файлы в директорию проекта, добавить плейсхолдеры — и ими сможет пользоваться вся команда. Он был крут. Как самурайский меч в фильме «Убить Билла». Ультимативный инструмент. Будь такой у крутого Сэма из одноимённой игры — можно было бы играть без мышки.\n\nСамые простые запросы выглядят максимально понятно и тривиально:\n\n![]({{strapiUrl}}\u002Fuploads\u002Fc229cdb95b86c1049941559d04563c9d_84b7a9765f.webp)\n\nНо есть возможность строить и сложные цепочки:\n\n![Полноценный сценарий для http-запросов в ConneKt]({{strapiUrl}}\u002Fuploads\u002F2f02b2631dabac783e5589596fca1136_d124da46c1.webp)\n\n> Но главное — это «кодовый» HTTP-клиент, который позволяет пользоваться подсказками среды разработки, автодополнением и привычными конструкциями, не требуя знания отдельного языка.\n>\n> Более того, учитывая то, что всё больше кода сейчас пишут именно агенты, а не люди, Connekt становится ещё более интересным инструментом. Skills заточенные под Connekt [уже доступны на GitHub](https:\u002F\u002Fgithub.com\u002FAmplicode\u002Fspring-skills) и их можно использовать с Claude Code, Codex, OpenCode и любым другим популярным агентом.\n\nДа, вы используете Kotlin DSL. И при этом вам вовсе не обязательно быть Kotlin-разработчиком или глубоко знать язык, хотя с некоторыми базовыми вещами познакомиться всё же придётся. Но не стоит относиться к этому настороженно: ничего сверхъестественного не потребуется. Все знания — типовые и во многом универсальные: похожие концепции есть в большинстве языков программирования. Здесь не нужны «семь пядей во лбу» — вы просто играете по понятным правилам.\n\nИ всё было отлично. Мы показали клиент широкой аудитории — и получили положительный отклик. Даже Роман Елизаров, автор coroutines в Kotlin, высоко оценил инструмент и отзывался о нём с большим энтузиазмом. Про это даже целое видео есть.\n\n\u003Cdiv class=\"video-player\" data-youtube=\"BBN3cjsmr8c\">\u003Ciframe src=\"https:\u002F\u002Fwww.youtube.com\u002Fembed\u002FBBN3cjsmr8c\" width=\"100%\" height=\"400\" frameborder=\"0\" allowfullscreen loading=\"lazy\">\u003C\u002Fiframe>\u003C\u002Fdiv>\n\nНо хотелось не только удобно перекладывать данные, но и проверять значения в ответах. Поэтому мы занялись поиском подходящего решения.\n\nПоскольку наш HTTP-клиент изначально живёт в Java\u002FKotlin-ландшафте, вариантов было много, и мнения разделялись. Однако в одном мы сошлись: всё необходимое должно быть «из коробки». Пользователь не должен думать о том, как подключать те или иные библиотеки для проверок. Наша цель была — не отвлекать его от написания сценариев и не заставлять разбираться в сторонних инструментах и их особенностях.\n\nМы попробовали разные библиотеки. Даже [Rest Assured](https:\u002F\u002Frest-assured.io\u002F) — с его богатым инструментарием — но столкнулись с техническими нюансами, например с подстановкой служебных заголовков.\n\nВ какой-то момент стало понятно: нам не хватает «просто проверок ответов» — без лишней сложности, но с красивым и гибким API.\n\nВ итоге мы остановились на AssertJ и Kotlin Power Assert. О них и поговорим далее.\n\n\u003Ch2 id=\"assertj\">AssertJ\u003C\u002Fh2>\n\n[AssertJ](https:\u002F\u002Fassertj.github.io\u002Fdoc\u002F) — это библиотека для тестирования, которая делает проверки понятными и читаемыми. Вместо сухого `assertEquals` ты пишешь что-то вроде `assertThat(user.age).isGreaterThan(18)`, и это буквально читается как фраза.\n\nЗа счёт этого проверки становятся не просто проверками, а чем-то вроде документации — по ним сразу видно, что именно ты ожидаешь от кода. Главный плюс AssertJ — удобство и ясность. Библиотека умеет красиво проверять списки, строки, исключения и даже целые объекты без необходимости писать кучу ручных сравнений.\n\nЕсли тест падает, ты получаешь нормальное, понятное сообщение: что ожидалось и что пришло на самом деле. В итоге меньше времени уходит на разбор, а сами тесты выглядят аккуратно и структурированно.\n\nОднако этого не всегда достаточно. Мы всё-таки пишем в Kotlin-like стиле, где ценятся стильные-модные-молодежные смузи результаты проверок, в которых сразу видно, что именно и где не сошлось.\n\n![Результаты проверок при помощи AssertJ]({{strapiUrl}}\u002Fuploads\u002Fa5fcdedd3f34bda7af279d2ce573e868_7e1eb376af.webp)\n\nНе могу не похвастать тем, что в нашем http-клиенте можно писать удобные проверки, которые выглядят клево.\n\nОднако, возможно пользователю не хотелось бы тащить дополнительные импорты в скрипты своих http-запросов. А подключение AssertJ этого требует. Так что мы оставили этот вариант доступным, но предоставили возможность пользоваться сравнениями из стандартной Kotlin-библиотеки.\n\n![AssertJ в ConneKt и импорт методов]({{strapiUrl}}\u002Fuploads\u002F2ccd7ac8f4c7d99bf1f8063048464f42_6880e78699.webp)\n\n\u003Ch2 id=\"kotlin-power-assert\">Kotlin Power Assert\u003C\u002Fh2>\n\nРаз уж речь зашла про Kotlin и его стандартные средства сравнения, грех не использовать все удобства по максимуму. Тем более что это совсем несложно. При этом мы не ожидаем, что наш пользователь обязательно является Kotlin-разработчиком.\n\n[Kotlin Power Assert](https:\u002F\u002Fkotlinlang.org\u002Fdocs\u002Fpower-assert.html) — это плагин, который делает обычные `assert` гораздо умнее и понятнее. Когда проверка падает, он не просто сообщает «false», а показывает, что именно внутри выражения пошло не так. Например, при сравнении значений он прямо в сообщении об ошибке выводит их реальные значения — и причина становится очевидной без дебага и лишних логов.\n\nЭто особенно удобно для простых проверок и формул, где важно быстро понять, какое условие не выполнилось. При этом Power Assert — не замена полноценным библиотекам вроде AssertJ, а скорее приятное дополнение, которое делает результаты сравнений более наглядными.\n\n![Проверки из стандартной Kotlin-библиотеки]({{strapiUrl}}\u002Fuploads\u002F10432b6cb6aecba5d43b619341e0a2f8_b6ec60dde2.webp)\n\nСогласитесь, это выглядит более кратко с точки зрения кода.\n\nА еще это добавляет наглядности результатам проверок.\n\n![Результаты проверок с Kotlin Power Assert]({{strapiUrl}}\u002Fuploads\u002Fc13d2042813269517424d78b224ae78f_4154e1dd97.webp)\n\nВот это уже прям красиво. В консоли буквально раскладывается по полочкам, что и где не сходится, а вынесение промежуточных значений в переменные добавляет коду аккуратности.\n\n`При этом можно задать собственное сообщение для падающей проверки, а сами скрипты — спокойно дебажить.`\n\n> Как вам такое, любители Postman? Всё ещё копируете значения руками между запросами?\n>\n> На самом деле все это шутки и ирония. У любого инструмента есть своя аудитория и безусловно Postman бывает хорош в ситуациях, когда у тебя под рукой нет среды разработки.\n\nНо это ещё не всё. Я могу сразу получать DTO, выстраивать цепочки запросов и затем выполнять проверки. И даже при работе с объектами вывод остаётся наглядным и понятным.\n\nВсем этим могуществом можно пользоваться уже сейчас. А главное, это бесплатно. Connekt доступен в бесплатной версии [Amplicode](https:\u002F\u002Famplicode.ru\u002F).\n\n\u003Ch2 id=\"eshhe-nemnogo-o-connekt-i-o-gryadushhem\">Еще немного о Connekt и о грядущем\u003C\u002Fh2>\n\nОднако мы пошли дальше и решили, что классно было бы проверять целые сценарии так, чтобы это было удобно. Далее я показываю возможности, которые еще недоступны на момент выхода статьи и станут доступны в грядущем релизе. Если вы хотите попробовать их уже сейчас, то напишите мне в личку :)\n\n![Проверки в Kotlin Power Assert для сценария.]({{strapiUrl}}\u002Fuploads\u002F7bfbf55a969bd42bb96bffd90af15de5_a7393d3257.webp)\n\nВ такие моменты видна вся красота Kotlin Power Assert. Он отлично работает для точечных проверок, когда важно понять, что именно пошло не так внутри конкретного выражения. Но в реальных сценариях этого часто недостаточно: хочется выполнить сразу несколько проверок, увидеть результат по всем из них сразу, а не падать при первой же проблеме сверки. Здесь на помощь приходят `soft assertions` — подход, при котором проверки накапливаются и выполняются вместе, формируя итоговый отчёт со всеми несоответствиями. Это даёт сильный эффект: вы получаете и наглядную детализацию каждой проверки, и полный контроль над сценарием целиком.\n\n![Soft Assertions]({{strapiUrl}}\u002Fuploads\u002Fdf34127691ebc9709b9794f47e6e762d_ffb0b0713e.webp)\n\nВсе гениальное просто! Сейчас в моем сценарии два запроса и две проверки. А может быть 10 и я всегда увижу все результаты.\n\nНо, у Kotlin Power Assert есть еще несколько клевых методов в API. Мы провели массу тестов и проверок для выявления сценариев, в которых пользуются Http-клиентами и это позволило нам подумать о читаемости кода и поддержать те, которые оказались уместны в рамках Http-клиента.\n\n![Методы require и check]({{strapiUrl}}\u002Fuploads\u002F4efa28411e7c778080d6c56bc8a45d31_de228d9ba5.webp)\n\nТак вместе с `soft assertions` в Connekt появились `require` и `check`. Мне кажется, все это дает огромный прирост надежности в борьбе с багами и проверках API. Ведь, это почти полноценные тесты. Представляете какая возможность автоматизации тестирования появляется, если добавить такие скрипты к автотестам для вашего тестового окружения! - Закачаешься! А ведь все эти вещи не надо писать руками. [Amplicode](https:\u002F\u002Famplicode.ru\u002F) умеет генерировать их для ваших Rest-контроллеров. Пара кликов и целая стена тестовых сценариев, позволяющая провалидировать написанный код и защитить его от багов. Пушка!\n\nЯ бы с удовольствием «блеснул шпагой» и показал ещё несколько классных трюков с использованием Connekt, которые появятся в ближайшем будущем, но цель этой статьи — продемонстрировать именно проверки и их силу, поэтому остальное оставлю на десерт.\n\n\u003Ch2 id=\"zaklyuchenie\">Заключение\u003C\u002Fh2>\n\nДля полноценной среды разработки необыкновенно важно иметь свой полноценный http-клиент. В разных IDE представлены разные варианты, мы в [OpenIDE](https:\u002F\u002Fopenide.ru\u002F) пользуемся Connekt. На мой взгляд - это лучший из имеющихся http-клиентов и точно самый функциональный и гибкий. Он позволяет не переключаться из среды разработки и не обрывать нить мышления. Про Connekt можно разговаривать много, но лучше один раз попробовать, чем 100 раз увидеть. Пользуйтесь удобным, модным и молодежным тулингом. А еще присылайте нам свои интересные кейсы и спользования. На этом у меня все. Благодарю за внимание.\n\n![]({{strapiUrl}}\u002Fuploads\u002Ffaaf4779c9a024185d697ad6a34d6a93_bed9f7f968.webp)\n\nАктуальные новости о продукте проще всего получать, подписавшись на наш [телеграм канал](https:\u002F\u002Ft.me\u002Famplicode). Получить актуальную версию [Amplicode](https:\u002F\u002Famplicode.ru\u002F) можно на [нашем сайте](https:\u002F\u002Famplicode.ru\u002F).\n\n---\n\n_Впервые опубликовано на [Хабре](https:\u002F\u002Fhabr.com\u002Fru\u002Fcompanies\u002Fhaulmont\u002Farticles\u002F1018588\u002F)._\n",[20],{"title":21,"links":22},"Содержание",[23,26,29,32,35,38],{"label":24,"href":25},"Kotlin DSL","#kotlin-dsl",{"label":27,"href":28},"Connekt","#connekt",{"label":30,"href":31},"AssertJ","#assertj",{"label":33,"href":34},"Kotlin Power Assert","#kotlin-power-assert",{"label":36,"href":37},"Еще немного о Connekt и о грядущем","#eshhe-nemnogo-o-connekt-i-o-gryadushhem",{"label":39,"href":40},"Заключение","#zaklyuchenie","2026-11-12T11:27:37.452Z","2026-11-13T12:20:58.075Z","2026-11-13T12:20:58.230Z",{"id":45,"documentId":46,"firstname":47,"lastname":48,"createdAt":49,"updatedAt":50,"publishedAt":51,"slug":52,"photo":53},38,"m8neann2s46tgq858cpr124q","Павел","Кислов","2026-02-15T12:49:47.587Z","2026-11-13T11:49:24.957Z","2026-11-13T11:49:25.060Z","pavel-kislov",{"id":54,"documentId":55,"name":56,"alternativeText":57,"caption":57,"width":58,"height":58,"formats":59,"hash":90,"ext":63,"mime":64,"size":91,"url":92,"previewUrl":57,"provider":93,"provider_metadata":57,"createdAt":94,"updatedAt":94,"publishedAt":94,"focalPoint":57},1358,"hpsfwiispy3prtyl96f3d4jx","Frame_59_1_f8af65a416.webp",null,1920,{"thumbnail":60,"large":69,"medium":76,"small":83},{"name":61,"hash":62,"ext":63,"mime":64,"path":57,"width":65,"height":65,"size":66,"sizeInBytes":67,"url":68},"thumbnail_Frame_59_1_f8af65a416.webp","thumbnail_Frame_59_1_f8af65a416_47e5d2e1a1",".webp","image\u002Fwebp",156,1.68,1678,"\u002Fuploads\u002Fthumbnail_Frame_59_1_f8af65a416_47e5d2e1a1.webp",{"name":70,"hash":71,"ext":63,"mime":64,"path":57,"width":72,"height":72,"size":73,"sizeInBytes":74,"url":75},"large_Frame_59_1_f8af65a416.webp","large_Frame_59_1_f8af65a416_47e5d2e1a1",1000,22.16,22162,"\u002Fuploads\u002Flarge_Frame_59_1_f8af65a416_47e5d2e1a1.webp",{"name":77,"hash":78,"ext":63,"mime":64,"path":57,"width":79,"height":79,"size":80,"sizeInBytes":81,"url":82},"medium_Frame_59_1_f8af65a416.webp","medium_Frame_59_1_f8af65a416_47e5d2e1a1",750,14.26,14258,"\u002Fuploads\u002Fmedium_Frame_59_1_f8af65a416_47e5d2e1a1.webp",{"name":84,"hash":85,"ext":63,"mime":64,"path":57,"width":86,"height":86,"size":87,"sizeInBytes":88,"url":89},"small_Frame_59_1_f8af65a416.webp","small_Frame_59_1_f8af65a416_47e5d2e1a1",500,7.77,7774,"\u002Fuploads\u002Fsmall_Frame_59_1_f8af65a416_47e5d2e1a1.webp","Frame_59_1_f8af65a416_47e5d2e1a1",82.09,"\u002Fuploads\u002FFrame_59_1_f8af65a416_47e5d2e1a1.webp","local","2026-11-13T11:47:14.953Z",{"id":96,"documentId":97,"name":98,"alternativeText":57,"caption":57,"width":99,"height":100,"formats":101,"hash":124,"ext":63,"mime":64,"size":125,"url":126,"previewUrl":57,"provider":93,"provider_metadata":57,"createdAt":127,"updatedAt":127,"publishedAt":127,"focalPoint":57},1217,"nj2jje594xl3aoyx7zvra46v","cover-kak-testirovat-api-pryamo-v-ide-ili-pochemu-ya-bolshe-ne-ispolzuyu.webp",780,440,{"thumbnail":102,"medium":110,"small":117},{"name":103,"hash":104,"ext":63,"mime":64,"path":57,"width":105,"height":106,"size":107,"sizeInBytes":108,"url":109},"thumbnail_cover-kak-testirovat-api-pryamo-v-ide-ili-pochemu-ya-bolshe-ne-ispolzuyu.webp","thumbnail_cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7",245,138,10.45,10452,"\u002Fuploads\u002Fthumbnail_cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7.webp",{"name":111,"hash":112,"ext":63,"mime":64,"path":57,"width":79,"height":113,"size":114,"sizeInBytes":115,"url":116},"medium_cover-kak-testirovat-api-pryamo-v-ide-ili-pochemu-ya-bolshe-ne-ispolzuyu.webp","medium_cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7",423,54.39,54390,"\u002Fuploads\u002Fmedium_cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7.webp",{"name":118,"hash":119,"ext":63,"mime":64,"path":57,"width":86,"height":120,"size":121,"sizeInBytes":122,"url":123},"small_cover-kak-testirovat-api-pryamo-v-ide-ili-pochemu-ya-bolshe-ne-ispolzuyu.webp","small_cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7",282,30.98,30978,"\u002Fuploads\u002Fsmall_cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7.webp","cover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7",66.74,"\u002Fuploads\u002Fcover_kak_testirovat_api_pryamo_v_ide_ili_pochemu_ya_bolshe_ne_ispolzuyu_8da278aac7.webp","2026-11-13T11:43:57.901Z",[129],{"id":130,"documentId":131,"title":132,"published":133,"weight":134,"slug":135,"createdAt":136,"updatedAt":137,"publishedAt":138,"color":57},4,"ap54riuwcv7sj63auhmb4i6d","Гайды",true,3,"guides","2026-11-12T11:20:31.298Z","2026-11-12T11:22:44.141Z","2026-11-12T11:22:44.122Z",{"pagination":140},{"page":141,"pageSize":142,"pageCount":141,"total":141},1,25,{"data":144,"meta":163},[145,151,157],{"published_date":146,"id":147,"documentId":148,"title":149,"slug":150},"2026-09-28",327,"lruxexelyn19uak89r6dney5","Что такое OpenSpec? Полный гайд по Spec-Driven Development","chto-takoe-openspec-polnyj-gajd-po-spec-driven-development",{"published_date":152,"id":153,"documentId":154,"title":155,"slug":156},"2026-09-10",326,"ymtfa6pslevvkrwnohdfbi1u","Как не потерять интеграцию с Docker в IDE после блокировки JetBrains","kak-ne-poteryat-integracziyu-s-docker-v-ide-posle-blokirovki-jetbrains",{"published_date":158,"id":159,"documentId":160,"title":161,"slug":162},"2026-09-01",400,"dskd9jsck2vjm1d0ztoz91uo","JavaScript и TypeScript в OpenIDE: Node.js, React, Angular, Git и работа с API","javascript-i-typescript-v-openide",{"pagination":164},{"page":141,"pageSize":134,"pageCount":165,"total":166},6,16,1794584600086]