Проектирование API *

Обычно процесс разработки API выглядит так: мы пишем контроллер. Затем каким-то образом его документируем. После чего фронтер, опираясь на такую документацию, пишет клиент.

Мы делаем одну и ту же работу трижды.

В прошлой статье я рассказывал, как избавиться от первого дублирования. С помощью бандла sunrise-studio/symfony-openapi можно генерировать OpenAPI-документ из кода, минуя процесс документирования.

Но это решает проблему только наполовину. Если OpenAPI-документ вытекает из кода, то клиент должен вытекать из OpenAPI-документа. Иначе написание клиента – и есть то самое дублирование.

В этой статье я расскажу как замкнуть цепочку:
Controller → OpenAPI → Client → Feature
Где каждый последующий шаг вытекает из предыдущего, а не дублирует его. 

Я хотел использовать Claude прямо в мессенджере MAX — без браузера, без переключения контекста. Готового решения не было. Нашёл на GitHub китайский проект cc-connect — Go-фреймворк с plugin-архитектурой для подключения AI-агентов к мессенджерам. Telegram, Feishu, Discord там были. MAX — нет.

Написал адаптер, открыл PR. Приняли. Теперь поддержка MAX — часть основного репозитория.

Что такое cc-connect

cc-connect — Go-фреймворк с чёткой трёхслойной архитектурой:

В июне 2026 года опубликован RFC 10008 — «The HTTP QUERY Method». Он добавил в HTTP новый стандартизованный метод QUERY, который также появился в реестре HTTP‑методов IANA: запрос с телом к конкретному адресу, который по смыслу остаётся чтением и не должен менять данные на сервере.

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

Обычный GET для таких запросов часто неудобен: параметры быстро превращаются в длинный URI или в собственный мини‑язык фильтрации внутри строки запроса. POST удобнее для передачи структуры, но передаёт не тот сигнал промежуточной инфраструктуре.

Приглашаю посмотреть, что там в RFC напридумывали, и чем нам это грозит — и чем поможет!

«Нам нужно сделать регрессионное, функциональное и интеграционное тестирование» — а ты автоматизатор и уже задумываешься о том, что попал куда‑то не туда. Или новичок решает пойти в тестировщики, смотрит вакансии и видит, что этих видов тестирования чуть ли не сотня. Как же понять, что от тебя требуют и куда идти? Попробуем разобраться.

Обычный LLM-агент, которого просят писать Python-скрипты под КОМПАС-3D, ошибается системно: придумывает несуществующие методы, путает две ветки COM API, ссылается на отменённые ГОСТы, подставляет невалидные значения в аргументы. Промпты и примеры это не лечат. В статье разбираю другой подход: контекст-слой из нескольких механизмов, где каждый класс ошибок ловится отдельно ещё до того, как код дойдёт до живого CAD. Внутри граф API на 47 тысяч узлов, справочник валидных значений, база действующих и отменённых стандартов, проверка сгенерированного кода настоящим C#-компилятором и разбор ошибок исполнения на живом КОМПАС-3D. С примерами кода и реальным фидбеком, который получает агент. Заодно объясняю, почему для такой задачи отказался от MCP.

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

Разбираю на Python-примерах, чем отличаются DTO, schema, model и entity — и когда отдельные классы действительно нужны.

Тестируем платформу Битрикс24 Вайбкод для создания полезных приложений в своём бизнес-портале с помощью ИИ-агентов.

Сегодня сделаем паспорт клиента: собираем в одном месте всё, что нужно знать о компаниях в нашем бизнес-портале: контакты, сделки, лиды и любые активности. Рассказываем по шагам свой опыт работы с платформой — что было просто, как строили работу, где ИИ ошибался и пришлось ли что-то исправлять вручную.

В этой статье - мой рабочий шаблон для описания REST API в ТЗ для разработчиков. В качестве примера я спроектировала учебную базу данных для финтех-системы. Она не привязана к реальному проекту и нужна только для того, чтобы показать, как описывать REST API по шаблону.

Недавно мне попалась отличная статья про IAsyncEnumerable и стриминг данных. В ней у автора упал прод, который пытался выдать 500 000 записей разом и упал на вызове ToListAsync() с OOM при 8 ГБ RAM. Далее в статье описывается, как все это стримить с помощью IAsyncEnumerable с примерами кода. В целом после прочтения статьи может сложиться впечатление, что все свои ToListAsync() срочно нужно убрать и заменить на стриминг.

Но со времен появления стримингового апи в .NET мне всегда было интересно, не только то как отдавать стримы, но и как это все получать на клиенте?

На прошлой неделе я снова потратил полдня на то, чтобы понять, почему фронт падает после обновления бэка. Локально работало, а на стейдже ошибка. Оказалось, бэкендер переименовал поле в ответе, но не обновил документацию и не предупредил команду. Я узнал об этом только когда код упал на стейдже - вручную править ручку пришлось уже постфактум, разбираясь с ошибкой.

С этим надо было что-то делать.

Думаю, многие хотя бы раз сталкивались с ситуацией, когда для проекта нужно было реализовать совсем небольшой backend: отправку письма с формы обратной связи, обработку webhook, простое REST API или несколько строк серверной логики. В большинстве случаев первым делом арендуют VPS, настраивают сервер, устанавливают Node.js, nginx, HTTPS и настраивают деплой.

Хотя для подобных задач это зачастую оказывается избыточным.

В таких случаях отличным решением становятся Google Cloud Functions — serverless‑сервис от Google, который позволяет написать небольшую функцию и уже через несколько минут получить готовый публичный HTTP endpoint. Не нужно поднимать собственный сервер, настраивать инфраструктуру или заниматься её поддержкой — достаточно написать код и задеплоить функцию.

В этой статье разберём, как за несколько минут развернуть свою первую Google Cloud Function, настроить автоматический деплой через GitHub Actions и использовать её в качестве простого backend для сайта, Telegram‑бота, webhook или любого другого проекта.

Если вы продаёте на двух и более маркетплейсах, вы почти наверняка с этим сталкивались: товар продан на Ozon, но на Wildberries он ещё висит в наличии. Приходит заказ на то, чего на складе уже нет. Дальше по сценарию: отмена, штраф, падение рейтинга карточки, в худшем случае - блокировка.

В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.

Привет, Хабр. Меня зовут Владимир Бурмистров, я главный системный аналитик холдинга Т1. В этой статье хочу посмотреть на WebSocket глазами системного аналитика и архитектора: от конкретики протокола HTTP 101 и фреймов до архитектурных решений с API Gateway, sticky‑sessions и формата постановок задач.

Хотел разобраться где заканчивается простой вызов локальной LLM и начинается backend система.

Сначала всё выглядело просто: frontend отправляет вопрос, FastAPI принимает POST /ask, backend вызывает локальную модель через Ollama и возвращает ответ. Но стало понятно: для помощника по документации этого мало. Модель отвечает, но непонятно на какие документы она опирается, какие фрагменты попали в prompt, сколько времени занял каждый этап и что делать, если индекс устарел.

В статье показываю не "как вообще устроен RAG", а путь от простого вызова локальной LLM к небольшому backend/RAG-проекту с API контрактом, request_id, логированием, sources, timings, rebuild index, negative tests и честными ограничениями.

Двоичный интерфейс приложений, чаще именуемый просто ABI — это концепция, которая кажется знакомой и незнакомой одновременно. В каком смысле знакомой? Об ABI часто говорят в контексте устранения неисправностей, упоминают в статьях. Иногда даже приходится решать проблемы с совместимостью, которые провоцирует этот интерфейс. А в каком смысле незнакомый? Дело в том, что, если кто-то попросит вас описать, что такое ABI — то вы обнаружите, что понимаете, о чём речь, но чётко сформулировать ответ на этот вопрос сложновато. В конце концов, можно ограничиться формулировкой, указанной в Википедии: «набор соглашений для доступа приложения к операционной системе и другим низкоуровневым сервисам, спроектированный для переносимости исполняемого кода между машинами, имеющими совместимые ABI». Возникает ли проблема с такой формулировкой? Нет, в качестве общего описания этого вполне достаточно. Но оно может казаться немного поверхностным.

На самом деле, в информатике такая ситуация встречается нередко. Информатика — это дисциплина, не стремящаяся к абсолютной строгости. У многих концепций нет чёткого определения, зачастую бывает достаточно, чтобы описываемый феномен был общепонятным. Итак, чтобы не увязнуть в определениях, давайте рассмотрим, что именно представляют собой такие двоичные интерфейсы, и какие факторы влияют на их стабильность.

Сейчас только ленивый не делает свой нодовый редактор.

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

Проект называется SnarkRoute. Рабочий публичный кусок сейчас живёт как BoojumRoute Lab — локальный блочный редактор маршрутов. А под ним лежит то, ради чего всё и затевалось: Open Route Protocol, переносимый формат для описания AI-, model- и API-воркфлоу.

Жизненный цикл разработки ПО (Software Development Life Cycle, SDLC) — это процесс управления программным обеспечением на протяжении всего времени его существования, от планирования до вывода из эксплуатации. API относится к программному обеспечению, поэтому термин «жизненный цикл API» синонимичен SDLC. Даже если ваш API не пройдет полный цикл, понимание того, из каких этапов тот состоит, поможет вам выработать подход к разработке.

Жизненный цикл API состоит из таких этапов, как: планирование, проектирование, реализация, тестирование, развертывание, сопровождение и выведение из эксплуатации.

Недавно исследовал интеграцию разных моделей. После танцев с бубном вокруг GigaChat решил проверить Yandex Cloud. Оказалось, нативная поддержка OpenAPI решает проблему без кастомных прокси. Внутри — готовые конфиги для OpenCode, Pi, Hermes и нюансы работы с Claude Code.

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

Вот только «стало лучше» — это ощущение. А ощущение нельзя положить в роадмап (или защитить перед руководством), чтобы сравнить через квартал. Улучшить то, что ты не измеряешь, нельзя: можно только верить, что улучшил.

Давайте сегодня разберёмся, как DX из набора интуиций превратился в измеримую дисциплину: с исследованиями, метриками и цифрами. И как этим пользоваться, не скатываясь в дашборд ради дашборда.

Рассказываем и показываем, как можно использовать мониторинг за кастомизациями Битрикс24. Для работы используем телеметрическую инфраструктуру на базе OpenTelemetry Collector — проект github.com/bitrix-tools/b24-ai-starter-otel.

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