Обновить
64K+

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

О создании API

49,58
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

NEOMSA APIM 4.6.0, платформа управления API: как мы устранили уязвимости Critical и High из БДУ ФСТЭК

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели9.8K

Мы выпустили NEOMSA APIM 4.6.0. Основной фокус этого релиза — повышение безопасности состава поставки платформы.

В рамках процессов безопасной разработки (SSDLC) мы сформировали SBOM, проверили компоненты и их зависимости на известные уязвимости (SCA), сопоставили результаты с БДУ ФСТЭК России и обновили проблемные библиотеки. По итогам повторной проверки количество зарегистрированных находок сократилось с 57 до 7. Уязвимостей уровней Critical и High в финальной сборке не осталось.

В статье рассказываем, как устроена проверка NEOMSA APIM перед выпуском и какой критерий безопасности мы используем для принятия решения о готовности релиза.

Читать далее

Как я перенёс проверку цен с VPS на компьютеры пользователей — и зачем всё-таки оставил сервер

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели7.8K

Сначала PriceTrack проверял страницы маркетплейса на VPS. Селекторы были корректными, но сервер вместо карточек товара получал 403. В итоге я перенёс браузер и извлечение данных на компьютеры пользователей, а сервер оставил управляющим контуром. В статье рассказываю, как устроена эта архитектура, зачем понадобились базовый профиль и локальный рецепт и какие проблемы появились с фоновыми проверками, треем и несколькими аккаунтами.

Читать далее

Wiremokjs как я создавал свой скриптовый язык для wiremock

Уровень сложностиСредний
Время на прочтение45 мин
Охват и читатели10K

В этой статье я расскажу, как создавал скриптовый язык WiremockJs — с нуля и до рабочего прототипа. Поделюсь, что меня подтолкнуло к этому «подвигу», как я проектировал грамматику, с какими ограничениями столкнулся и почему в итоге не стал использовать JavaScript, а написал свой упрощённый диалект. Под катом — ANTLR, парсеры, немного боли и много удовольствия от творчества.

Читать далее

Ваш AI‑агент не ошибся. Он точно выполнил плохую спецификацию

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели8.4K

Почему API-First уже недостаточно и что меняется, когда SDD строится на .md-файлах и обязательном участии агентов?

В агентном SDD спецификация становится не пояснением к коду, а рабочим контекстом, из которого агент строит план, тесты и реализацию. Это ускоряет разработку — и одновременно увеличивает цену неоднозначности. Разбираем, как превратить .md из документации в управляемый контракт.

Читать далее

Как облегчить переезд бота из Telegram в MAX

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели9.8K

В связи с тем, что Павел Дуров теперь террорист, Telegram скоро признают экстремистской сетью, что окончательно выведет бизнес в черную зону. Несмотря на то, что мы видим, как до сих пор всё прекрасно работает в соц.сети с картинками, важно перестраховаться. Поэтому сейчас, чтобы “обелиться”, многие бизнесы и эксперты переезжают или будут переезжать в другие соц.сети, в том числе в тот, который ловит даже на парковке

Если вам кажется, что для перевода бота с Telegram на МАХ достаточно пары кликов: получить токен, поменять адрес API и подключить прежние обработчики, то, к сожалению, все не совсем так. Обычно это намного сложнее, ведь у платформ отличаются события, кнопки, медиа, работа с мини-приложениями и идентификаторами.

А если вам не повезло и в проекте намешаны бизнес-логика и код конкретной платформы, то скорее всего, надо будет написать практически нового бота

Читать далее

Один платёж — один чек: идемпотентность в интеграции с «Мой налог»

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели8.7K

Я делаю сервис по подписке и плачу налог как самозанятый. Пока платежей было три в день, чеки в «Мой налог» можно было выбивать руками. Когда они пошли круглосуточно, понадобилась автоматика — и выяснилось, что сложное в этой задаче не API налоговой, а один вопрос: что делать, когда запрос ушёл, а ответ не вернулся. Повторить — риск выдать человеку второй чек на ту же сумму. Не повторить — риск не выдать вовсе.

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

Читать далее

Избавляемся от потерянных событий в микросервисах — как я написал свой Spring Starter для Outbox/Inbox

Время на прочтение12 мин
Охват и читатели8K

Всем привет! Меня зовут Григорий, и недавно при разработке своего микросервисного приложения я нашёл уязвимость — сообщения, пересылаемые между сервисами, имели высокий риск быть необработанными. Решением стал паттерны Outbox и Inbox. Однако, когда я стал их реализовывать во всех приложениях, то понял, что просто копирую и вставляю код. Чтобы это исправить, я решил написать свой стартер.

Читать далее

350+ моделей без смены SDK: зачем разработчику слой абстракции над LLM‑провайдерами

Уровень сложностиСредний
Время на прочтение15 мин
Охват и читатели9.2K

Привет, Хабр! На связи команда Caila — платформы Just AI, объединяющей LLM и другие генеративные модели, включая модели для создания изображений и видео.

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

Читать далее

KrakenD: как мобильная логика расползлась по монолиту, а мы собрали её обратно

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели6.8K

Всем привет! Меня зовут Рома, я бэкенд-инженер в Банки.ру. Мы перевели мобильное API на KrakenD, и сейчас через него идёт весь трафик приложения.

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

Читать далее

OAuth‑сервер, который не хранит пользователей

Уровень сложностиСредний
Время на прочтение23 мин
Охват и читатели7.4K

Наш OAuth-сервер не хранит профиль пользователя и практически ничего о нём не знает. Он знает только IdP-личность («вы вошли через Google под таким-то аккаунтом»), а внутренний id, роль и имя живут в продуктовом бэкенде. Сшивают их два кастомных гранта: первый вкладывает в токен подписанный профиль, не зная его содержимого, а второй разменивает основной токен на веер узких производных, по одному на аудиторию. Кроме того, в статье объясняется, почему FedCM может создавать больше проблем, чем решать, и как эти проблемы обходятся с помощью Service Worker. Если вам интересно, как всё это работает в SaaS, прошу под кат.

Читать далее

Гибкая фильтрация EF Core с помощью Expression. Часть 2: Roslyn Source Generator

Уровень сложностиСредний
Время на прочтение15 мин
Охват и читатели9.8K

Для своего пет-проекта мне понадобилась удобная система фильтрации, плюс я хотел попрактиковаться в кодогенерации Roslyn. В этой статье продолжаю рассказывать о гибкой фильтрации данных в EF Core на Exression. Расскажу как мне удалось реализовать новые фичи (строгий контракт с фронтом, операторы сравнения, автоматический null-guard) выиграв при этом в производительности в рантайме.

Читать далее

Назад в 2005-й. API-first как третья пилюля от деградации проекта под LLM

Время на прочтение19 мин
Охват и читатели9.6K

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

Под катом — как этот шов гниёт под LLM и как его чинит contract-first: генерация серверных интерфейсов и клиента из одного OpenAPI-файла, политика ломающих изменений, правило «не симулируй — расширяй контракт». Попутно — зачем возвращаться к идее, которую мы выбросили вместе с WSDL, и какая из моих проверок после всего этого молча перестала работать. Третья часть цикла, читается самостоятельно.

Читать далее

Анти‑паттерн ИИ: Смертельная триада

Уровень сложностиПростой
Время на прочтение10 мин
Охват и читатели9.2K

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

Разбираю «Смертельную триаду» (The Lethal Trifecta): сочетание приватных данных, недоверенного контента и возможности действовать во внешнем мире. Показываю, почему проблема не в «плохих» моделях, а в устройстве современных агентных систем, какие популярные способы защиты не дают структурных гарантий и как размыкать эту комбинацию на уровне архитектуры. В конце приведён короткий обзор направлений, которые могут сделать ИИ‑агентов не только полезными, но и принципиально более безопасными.

Читать далее

Ближайшие события

Как я научил Claude заказывать продукты в Яндекс Лавке (и что для этого пришлось отреверсить)

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели14K

У Яндекс Лавки нет публичного API. А мне захотелось написать ассистенту «закажи молоко и что-нибудь к ужину» — и чтобы заказ реально уехал курьеру.

Рассказываю, как я отреверсил приватный веб-API Лавки прямо из браузерного трафика и завернул его в MCP-сервер: поиск, корзина, оформление с подтверждением суммы. А главное — про грабли, которые ловил воспроизведением, а не «на глаз»: заголовок X-CSRF-Token, зашитый в HTML; гонки за общую корзину и HTTP 409; «Раскупили» и «только из Большой Лавки», которые оказались не тем, чем выглядели; пустой способ оплаты; и удалённый деплой с OAuth, чтобы заказывать с телефона.

Код открыт (MIT), ставится через uvx. Осторожно: неофициально, реверс приватного API, оформление тратит реальные деньги.

Читать далее

Как мы показываем клиентам документацию по проекту из приватного репозитория, не пуская их в репозиторий

Уровень сложностиСредний
Время на прочтение3 мин
Охват и читатели12K

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

За последний год мы переписали почти всю проектную документацию в markdown и положили в тот же git, где лежит код. Причина простая: после перехода на Cursor и Claude Code так было удобнее работать. Модели нормально обрабатывают markdown и не лопатят десятистраничный google-док, диффы видно в PR, доки лежат рядом с кодом, который описывают. Всегда можно обратиться к инфе по проекту, внести обновления - короче пользоваться документом, а не хранить его для красоты.

И тут вылезла проблема, о которой лично мы заранее не подумали: документацию читает не только тот, кто её пишет. Её читают клиенты, менеджеры, дизайнеры, эйчары. А они в репозиторий не полезут никогда.

Дать клиенту доступ в GitHub/GitLab — так себе затея сразу по нескольким причинам: там лежит то, что ему видеть не надо, это лишний разговор про безопасность, да и сам интерфейс гитхаба человека не из айтишки отпугивает. Плюс требуется регистрация. В итоге мы делали то же, что, по-моему, делают все: копировали markdown в google docs, чтобы клиент мог прочитать и покомментировать, а потом при каждом изменении заново выгружали и сводили комментарии руками. Год так жили.

Что смотрели, прежде чем пилить своё:

GitBook и Mintlify хотят, чтобы ты писал в их редакторе. Ради шеринга пришлось бы бросить тот самый workflow, ради которого мы в git и переехали. Плюс ценник.

Читать далее

ИИ-агент работает, пока ему не дали доступ к реальным данным. Что ломается в проде?

Уровень сложностиПростой
Время на прочтение13 мин
Охват и читатели7.5K

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

Здесь кроется главное противоречие внедрения LLM. Без доступов агент бесполезен, а с ними — превращается в потенциально опасного инсайдера. Любая ошибка в чате может обернуться реальным запросом к системе от имени служебного аккаунта, и ограничения в промпте вроде «не брать чужое» здесь не помогут.

Именно этот разрыв между красивым демо и суровой энтерпрайз-реальностью стал темой дискуссии на канале Ai4Dev.

Читать далее

Проектируем шеринг вещей с нуля за 250 тысяч рублей

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели11K

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

Читать далее

Бот в MAX молчит: четыре грабли Bot API, на которых я потерял неделю

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели8.6K

Синяя галочка есть. Ответа нет. Мой собственный бот в MAX игнорирует моё же сообщение: сервер отвечает 200 OK, в логах чисто, а человек на другом конце ничего не видит. Так начались четыре вечера отладки Bot API нового российского мессенджера — четыре грабли, которых нет в документации. Где живёт токен. Почему 404 на чат, в котором ты прямо сейчас переписываешься. Как молча испаряется webhook-подписка. И почему MAX не говорит, которому из твоих ботов написали. Собрал всё, чтобы следующему хватило получаса вместо недели.

Читать далее

Два изображения, очередь и proxy: как мы подключили OpenAI Image Edits к российскому production-серверу

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели9.7K

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

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

Одной из творческих активностей стала «виртуальная роспись» городского здания. Пользователь выбирал фотографию фасада, загружал собственный рисунок, а система превращала его в изображение на стенах. Здание должно было остаться узнаваемым, а рисунок - стать частью реальной архитектуры, а не потеряться в новой генерации.

На уровне интерфейса всё выглядит просто: выбрать основу, загрузить рисунок, дождаться результата. На уровне production-системы задача быстро перестаёт быть «вызовом AI API». Прямого доступа к OpenAI API с российского сервера нет. Сама операция длительная, работает с приватными файлами и может завершиться сетевой ошибкой, ограничением провайдера или отказом модерации.

Ниже - технический разбор этого конкретного потока: от React и очереди Laravel до небольшого собственного proxy-сервиса, встроенного в архитектуру основной платформы.

Читать далее

Multi-tenant Битрикс24 в трёх проектах: три архитектуры OAuth-токенов и лицензирование через материнский смарт-процесс

Уровень сложностиСложный
Время на прочтение11 мин
Охват и читатели8.1K

За полгода написал ряд интеграций с Битрикс24 в разных архитектурах: приложение для Маркета (PHP, 6 порталов), клиентский расчётный сервис (Node.js + PostgreSQL) и cron-синхронизатор legacy-CRM без UI и без OAuth вообще. Мультитенант везде решён по-разному, и это не случайность, ведь каждая архитектура точно закрывает свою нишу.

Внутри: сравнение трёх способов хранить OAuth-токены под 6+ порталов, разбор пяти неочевидных деталей REST API (oauth.bitrix24.tech-обход, POST vs GET на рефреше, rate limit 2 req/sec, batch на 50, буфер 5 мин), куски кода на PHP и TypeScript.

Отдельная часть — лицензирование через материнский смарт-процесс. У продукта, распределённого по клиентским порталам, нет своего backend’а, поэтому control-plane я вынес на служебный портал агентства: смарт-процесс «Лицензии», бизнес-процесс на изменение счётчика запросов, webhook approve/decline с secret. Такого паттерна в документации Битрикс24 нет — а он работает уже несколько месяцев и не требует ничего сверх штатной функциональности платформы.

Матрица «что выбирать под задачу» в конце.

Читать далее