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

Если бот копирует один и тот же пост в десять каналов, в Google Analytics все клики свалятся в одну кучу. URL у скрытой ссылки живёт не в тексте, а в MessageEntity, а copyMessages копирует его как есть. Ниже — как пересобрать пост под каждую площадку, не сломав жирный шрифт, эмодзи и health‑check.

Telegram умеет одно очень удобное действие: copyMessages. Берёте сообщение из чата A, кладёте в чат B — форматирование, медиа, альбом, скрытые ссылки, всё на месте. Для рассылок и зеркал это идеальный метод.

Для рекламы он ломает самое важное.

Рекламодатель покупает размещения в разных каналах и смотрит в свою аналитику: откуда пришёл клик. Если во всех десяти постах в text_link лежит один и тот же https://shop.example/sale, UTM бесполезен. Каналы неразличимы. Сделка неразличима. Дата размещения неразличима.

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

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

В этой статье разберу более устойчивый вариант: отдельный API‑слой между мобильным приложением и существующей системой. Без полной переработки монолита и без попытки сразу перейти на микросервисы.

Корпоративные команды используют MCP-шлюзы, чтобы контролировать, как ИИ-агенты получают доступ к инструментам, сервисам и корпоративным данным. Agentgateway, проект с открытым исходным кодом, развиваемый под эгидой Agentic AI Foundation, маршрутизирует MCP-, Agent-to-Agent-, LLM- и API-трафик между клиентами и внутренними сервисами. Его открытый код, тесты и рекомендации по безопасности делают его полезным объектом для практического изучения безопасности корпоративных шлюзов.

Почему мы классифицируем движение руки, а не картинки со светофорами — и как встроить это в форму двумя строками

Картиночные капчи в 2026-м решаются моделями компьютерного зрения за миллисекунды, а каждый ваш клик по «выберите автобусы» бесплатно размечает чужой датасет. Плюс две свежие проблемы: Google в начале 2025 срезал бесплатный лимит reCAPTCHA с 1 000 000 до 10 000 проверок в месяц, а с апреля 2026 ужесточил модель ответственности за данные по GDPR. Из России reCAPTCHA к тому же нестабильна.

Общая проблема для сети — как доказать, что ты человек, не сдавая паспорт, лицо и номер телефона. Мы предлагаем: drop-in капчу, которую посетитель не кликает, а рисует. В описании — архитектура, ML-часть, приватность и код интеграции. Проект открытый. Буду рад аргументированным замечаниям.

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

Внутри: как собрать промпт-карту и почему её нельзя писать до замера спроса, чем российский стек отличается от западного, отдельная директива в robots.txt, о которой мало кто знает, и во что обошёлся весь замер — 102 рубля.

Задача звучит просто: выяснить, называют ли бренд ChatGPT, Claude, Perplexity, Gemini, Алиса AI и GigaChat, когда пользователь спрашивает совета или ответа у ИИ. На практике эта задача раскладывается на десятки технических решений, каждое из которых меняет результат в разы. Ниже устройство замера, формат хранения и три моих ошибки, которые обесценивают всю работу.

Цифру «+1100%» я увидел в чужом пересказе, и это ровно тот жанр новости, после которого приходят спрашивать, что будет со сметой. Часть нашей нагрузки на DeepSeek пакетная, ее можно двигать по времени суток, так что вопрос был прикладной: насколько сильно двигать и куда.

Я открыл прайс, взял профиль своей нагрузки, перемножил. Получилось 2,3. Перепроверил на других профилях, получилось от 2,3 до 2,9. Роста в 11 раз не вышло нигде.

Дальше выяснилось, что 12,1 существует, живет ровно в одной клетке прайса из шести и весит в счете меньше 10%. А по дороге я наткнулся на вещь поинтереснее: пиковые окна DeepSeek объявил в UTC, и в московском времени они ложатся так, что из рабочего дня дорогим оказывается ровно промежуток с 10:00 до 13:00, после чего до 04:00 следующих суток все идет по дешевому тарифу.

Ниже разбор прайса, реверс-инжиниринг пиковых окон, таблица «найдите свой часовой пояс», калькулятор на 40 строк и фрагмент crontab, который сдвигает батч за 13:05.

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

Через несколько дней (говно)кода стало много — вменяемого сервиса не получилось.

Один BFS принимал map[string][]string. DFS жил на другом типе графа. В одной реализации направленность задавалась на уровне графа, в другой вытекала из того, как было записано ребро. Опции существовали, но их комбинации не образовывали понятной политики. Result types возвращали срезы и числа, однако я не мог внятно ответить, что именно они гарантируют.

Проблема была не в том, что LLM «не умеет BFS». Я попросил реализации раньше, чем сформулировал общий контракт данных. Генератор заполнил пустые места правдоподобными допущениями — которые, очевидно, не совпали в разных кусках кода.

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

В начале августа я сел делать игру для мессенджера MAX – обычный вордли, слово из пяти букв, шесть попыток. Мини-приложение на ванильном JS, сервер на Go, самый дешёвый VPS. По моим прикидкам – три вечера.

Первый вечер целиком ушёл на то, чтобы сервер вообще смог поговорить с API мессенджера. Не на игру, не на словарь – на TCP-соединение.

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

Собрал шесть AI-сервисов, которыми сейчас можно пользоваться бесплатно или с крупными стартовыми кредитами: FLUX 3 для генерации видео, Manus, Postman Agent Mode, Claude через API, Atomesus и Deepgram с $200 на Voice AI. Проверил регистрацию и условия на своих аккаунтах, добавил скриншоты и короткие инструкции. Актуально на 12 августа 2026 года.

Держите открытыми две вкладки. В одной — интернет-банк, куда вы залогинены и где на экране висит ваш баланс. В другой — какой-то сайт, на который вы забрели по ссылке из выдачи, ничего особенного. Теперь вопрос, который на первый взгляд кажется надуманным, а на деле упирается в фундамент всей веб-безопасности: что мешает скрипту со второго сайта взять и прочитать ваш баланс из первого?

Encore зародился как фреймворк на Go, и на Go там были написаны среда выполнения, интерфейс командной строки (CLI), парсер и компилятор. Когда мы решили поддерживать TypeScript, логичнее всего было бы написать на TypeScript и среду выполнения тоже, либо достроить к среде выполнения Go какой‑нибудь мостик. Но в итоге пришли к тому, что написали новую среду выполнения с нуля на Rust.

Привет, Хабр! Я Матвей Лихота, старший Go-разработчик. В предыдущем материале я показывал, как получить Go-код из OpenAPI. Теперь хочу сделать еще один шаг назад — к моменту, когда контракта еще нет.

На демо частенько можно увидеть, как по простому запросу «напиши CRM» или «собери интернет-магазин» LLM уже через минуту готовит сервер, модели, миграции и тесты. Но в реальности, конечно, все происходит чуть иначе: проверяем код, а там — сюрприз-сюрприз ошибки. Повторив тот же промпт, мы получим другую архитектуру и снова потратим время на проверку. И нет гарантии, что после переделки ошибок не станет еще больше.

Конечно, все дело в промпте. Согласитесь, странно просить модель понять задачу, выбрать архитектуру, определить границы и все реализовать за один шаг? Что, если LLM сначала проектирует систему и выпустит OpenAPI, Proto, JSON Schema, CloudEvents и AsyncAPI? А код мы добавим чуть позже: за повторяемую часть будут отвечать обычные генераторы, а за проектно-зависимую — разработчики и агент в контексте репозитория.

Такой подход, где главным артефактом становится контракт, а код — его производной, можно назвать Documentation Driven Agent Development или Specification Driven Agent Development. Как он работает — покажу на примере разработки простой автоматической телефонной станции (АТС), а еще проведу границу между генераторами и агентами.

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

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

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

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

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

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

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

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

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

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

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

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

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