Всю свою карьеру разработчика я пользовался Postman. Помню его ещё простым расширением Chrome, слегка облегчавшим тестирование API. Жизнь в времена была гораздо проще. Сегодня я присоединяюсь к растущей толпе разработчиков, отказывающихся от этих инструментов, потому что они продались.

Великое предательство: как наши любимые инструменты обернулись против нас

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

Postman, когда-то бывший любимцем всех разработчиков, стал наглядным примером такой трансформации. Переломным для многих моментом стало удаление Scratchpad (офлайн-режим). После этого — снижение производительности и привязка к облачному сервису. Внезапно мы оказались вынуждены синхронизировать свою работу с облаком Postman для доступа к базовому функционалу (привет, Microsoft?). Во-первых, это вставляет палки в колёса разработчиков, работающих над конфиденциальными проектами в сфере банкинга и здравоохранения, а также в государственном секторе. В этом и есть смысл — заставить их платить за инструмент, максимизировать прибыль руководства, поэтому наносимый отрасли сопутствующий ущерб не учитывается.

Я пробовал обойти эту проблему, попытавшись пользоваться «Lightweight API Client», который оказался урезанной и едва работающей версией. В конце концов я сдался и стал искать другие решения.

Insomnia, позиционировавший себя как чистую альтернативу Postman, пошёл по тому же пути, его архитектура стала копией Postman. Версия 8.0 запретила пользователям использовать собственные коллекции, демонстрируя экран обязательного логина. Реакция сообщества была наглядной и яростной, но форк забросили и им, вероятно, уже никто не пользуется, а оригинальный продукт стал «ещё одним корпоративным активом».

Thunder Client, расширение VS Code, обещавшее простоту использования, совершило то, что можно описать только как недобросовестная реклама. После того, как разработчики интегрировали его в свои рабочие процессы, владельцы спрятали функцию сохранения запросов к локальным репозиториям Git за пейволом. Это стало не просто бизнес-решением, а ещё одним предательством сообщества разработчиков, помогавшего продукту развиваться. А работать над расширениями VS Code крайне неудобно.

Кризис производительности: почему работа с этими инструментами напоминает барахтанье в грязи

Если отставить в сторону вопросы этики, на практике огромной и важной проблемой стала производительность. Обещанное Electron «напиши один раз и код будет работать везде» превратилось в «везде работает плохо». На моём MacBook M1 Pro для запуска и загрузки Postman требуется больше десяти секунд. Он съедает гигабайты ОЗУ для отправки простого GET-запроса, и со временем становится только хуже. Ужасная ситуация для продукта, который даже проще, чем IDE.

Раздувание связано не только с ОЗУ, но и с UI. Postman мутировал в платформу, которая пытается одновременно быть всем: репозиторием API, социальной сетью, mock-сервером, фреймворком тестирования. Девяносто процентов разработчиков просто хотят пинговать конечную точку и получать JSON. Вместо этого мы уклоняемся от всплывающих окон и меню, предназначенных для корпоративных отделов продаж, а потом упираемся в стену регистрации или пейвола.

Изучение современных альтернатив

Эти проблемы заставили сообщество искать инструменты, которые ценят простоту и, что более важно, Git Workflow. Чаще всего вспоминают название Bruno. Он опенсорсный и хранит коллекции в виде незашифрованных файлов на диске, поэтому я могу управлять версиями тестов моего API прямо рядом с исходным кодом в том же репозитории (невероятно, правда?).

Он далеко неидеален: UI не хватает лоска, а миграция болезненна — скрипты часто ломаются, потому что JavaScript-песочница не такая, как у Postman. Также ему недостаёт мощных корпоративных фич, например расширенной поддержки прокси. Но обещают, что он будет уважать нас, пользователей. По крайней мере, пока

Как должен выглядеть идеальный инструмент для API

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

• Поддержка импорта спецификаций OpenAPI и схем GraphQL, а также простая поддержка тестов.

• Отсутствие ограничений логинами. Инструмент работает полностью офлайн без принудительного создания аккаунта или обязательной синхронизации с облаком.

• Нативная совместная работа в Git. Совместная работа происходит через стандартные системы управления версиями, а не через платные лицензии «за место» или проприетарные синхронизации с облаками.

• Нативная производительность. Написан на высокопроизводительных языках (например, на Rust), а не через веб-обёртки. Открывается мгновенно, потребляет минимальные ресурсы.

• Расширяемая архитектура. Модульная архитектура плагинов, добавляющая функциональность и не раздувающая основное приложение.

• Универсальные импорты. Нативная поддержка импорта спецификаций OpenAPI, схем GraphQL, коллекций Postman.

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

• Потоки скриптинга и аутентификации. Перехват до запросов и после ответов.

• Простое тестирование. Встроенная поддержка написания и запуска тестов ответов API в коде.

Что дальше?

Инструментарий API сегодня — это или раздутые облачные монстры, или легковесные открытые локальные новички. На каждый Postman или Insomnia есть свой Bruno, Hurl или Httpie; каждый из них находится на определённом месте в спектре, но ни один инструмент не охватывает всего. Некоторые слишком голые, другие требуют доработки; какой бы я ни изучал, всегда есть ощущение, что чего-то не хватает.

Но может быть, это и хорошо. Возможно, мы всё ещё ждём того, благодаря кому нам больше не придётся идти на компромиссы. Надеюсь, что кто-нибудь над этим работает. Может быть, это вы. Может быть, я. Лучший инструмент, наверно, ещё не создан.

Дополнение за март 2026 года:

Так-так. Postman только что выпустил так называемый Native Git — коллекции, хранимые в виде файлов YAML в файловой системе, ветви, соответствующие реальным ветвям в Git, офлайн-режим, Works. Звучит знакомо? Да это буквально то, что обещал нам Bruno, спрятанное за пейволом в $19 на пользователя в месяц. Владельцы даже полностью убили бесплатные тарифы для команд — тариф Free теперь только для одиночек, поэтому если ваша команда из трёх человек работала в Postman за ноль долларов, то поздравляю, теперь это $684 в год. Совместная работа за мгновение превратилась из «бесплатной фичи» в «отмеренный ресурс».

И вот что меня раздражает: «рекомендованный рабочий процесс» по-прежнему заключается в postman workspace push для синхронизации всего обратно в облако. Существует «локальный режим» и «облачный режим»; догадайтесь, какой предназначен для всех корпоративных фич, которые они на самом деле хотят нам продать? Естественно, облачный. Так что да, строго говоря, ваши файлы теперь хранятся на диске, пока вам не понадобится поработать вместе; тогда вы снова возвращаетесь в облако Postman и платите за место. Владельцы увидели, что люди сбегают от них на локальные инструменты, скопировали поверхностную фичу и прикрутили её к той же бизнес-модели с привязкой к облаку. Как будто приделали гоночный спойлер на трактор. Наверно, направление движения верное, но мотивация не поменялась.