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

Alibaba Cloud Model Studio (Сингапурский регион) даёт бесплатную квоту новым пользователям: 1 000 000 токенов на каждую модель. Не на аккаунт, а именно на каждую модель отдельно. То есть вы получаете по миллиону на Qwen-Max, Qwen-Plus, Qwen-Flash, Qwen3-Coder-Plus и так далее — параллельно.

Квота действует 90 дней с момента активации.

Что доступно

Полная линейка Qwen3:

Qwen-Max — флагман, сложные multi-step задачи, контекст 32K

Qwen-Plus — баланс качества и скорости, контекст до 1M токенов

Qwen-Flash — быстрая и дешёвая, тоже до 1M контекста

Qwen3-Coder-Plus/Flash — специализированные для кода, контекст до 1M

Qwen-VL — мультимодальные (текст + изображения)

Qwen-OCR — извлечение текста из изображений, поддержка русского

Qwen-Omni — аудио, видео, мультимодальность

Плюс открытые модели (qwen3-235b-a22b и другие) тоже доступны через API с квотой.

Если ваш API-клиент выглядит как башня декораторов — вы уже в зоне инженерной боли. Рассказываю, как я из этого выбрался.

Что делать, если после статьи на Хабре количество пользователей выросло вдвое (даже если их стало всего десять)? В этой статье я пройду путь от "крепкого" монолита до взрослой архитектуры с разделением на API, Web и Auth. Поделюсь опытом создания изолированного тестового контура и разберу, почему модная связка Bun + Vercel на реальном продакшене может стоить вам нескольких седых волос и часов дебага.

Меня зовут Никита, я ведущий инженер‑программист финансового маркетплейса «Выберу.ру». Этой статьей я хочу предотвратить распространение мифа о том, что Цифровой профиль переходит в офлайн-режим взаимодействия из-за перехода с REST API на СМЭВ.

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

Основная мысль статьи в том, что нет никакой офлайн-версии Цифрового профиля в процессе удаленной выдачи займа.

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

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

Типичный сценарий: бизнес приходит с задачей "Если в корзине три товара категории "Электроника", положи в подарок чехол, но только если регион доставки не "Дальний Восток". Звучит как if-else на пять строк. Но в распределённой системе это превращается в такой себе квест: BasketService синхронно обращается к Catalog, затем к Warehouse, затем к GeoService. Где-то посередине случается таймаут, где-то - сетевой сбой, и в коде начинают появляться саги, компенсации и ретраи.

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

Я приглашаю сегодня взглянуть на проблему под другим углом. Что если пересмотреть не инструменты, а саму парадигму управления состоянием?

После негодования по поводу реализации паттерна Repository в обучающих материалах, а именно скудность функционала, я решил, что нужно расширяться и это привело к тому, что появился ORM Query Builder, о котором подробно расскажет вам эта статья.

Кеш — это не просто «быстрая память». То, как ваше приложение взаимодействует с кешем, определяет согласованность данных, сложность кода и отказоустойчивость. Выбор паттерна зависит от сценариев нагрузки: read-heavy, write-heavy или mixed.

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

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

Меня зовут Никита Бугуев — я бэкенд‑разработчик на Python в команде, которая разрабатывает открытое банковское API и пытается захватить контроль над всеми интеграциями наружу. В статье расскажу, как мы написали свои велосипеды для вебхуков и какие грабли собрали по пути.

Привет, Хабр.

Хотим вам рассказать об одной из первых наших новинок 2026 года, которую с тем же успехом можно считать и вторым изданием, и переизданием отлично зарекомендовавшей себя книги о микросервисах. Речь под катом пойдёт о книге Юлии Поповой «Go: разработка приложений в микросервисной архитектуре с нуля».

И даже до выхода у этой книги уже есть история.

Авторизация пользователя в Telegram mini-app сейчас как никогда важна. Но что если вам необходимо сделать это в вашей сервисной/микросервисной архитектуре с отправкой смс-кода?

В эпоху цифровизации, Вы когда-нибудь задумывались, существуют ли способы значительно снизить затраты на разработку ИТ-решений? И речь не про жалкую экономию в 5-10%, а именно экономию в разы, когда от прототипа до ввода в промышленную эксплуатацию - достаточно несколько дней разработки. Не месяцы, не годы, а именно дни. Особенно это актуально для инжиниринговых, конструкторских или производственных компаний, которые по своей сути не являются разработчиками ИТ, но вынуждены здесь и сейчас обеспечивать собственные нужды различными ИТ-решениями.

Есть рутина, которую вы мечтаете автоматизировать? Или идеи, чего не хватает в повседневной работе? Напишите в комментариях или мне на почту (она в конце поста). Буду рад любым предложениям: что добавить, что упростить, а что вообще переделать.

Нейросети научились писать код, но до недавнего времени оставались беспомощными в реальном мире софта. Протокол MCP (Model Context Protocol) убрал эту стену, дав моделям прямой доступ к инструментам. И если для веба коннекторы появились сразу, то инженерный софт незаслуженно забыли. Я решил это исправить и дал нейросети прямой доступ к API КОМПАС-3D.

Где-то между 2006 и 2008 годами в головах нескольких людей, которые слишком много думали про HTTP и REST, родилась не самая очевидная мысль: а что, если вместо того, чтобы каждые N секунд дёргать чужой API и спрашивать «ну что там у вас новенького?», заставить этот самый API самому постучаться к нам, когда ему действительно есть что сказать?

Сейчас это звучит как база, почти как «а давайте вместо FTP будем использовать git», но тогда это было довольно радикальным сдвигом парадигмы. От pull к push. От клиента-инициатора к серверу-инициатору.

Привет, Хабр!

Типичная картина ИТ-хакатона: команды тратят время не на продукт, а на борьбу с инфраструктурой. Документация есть, API есть – а собрать реальный сценарий нельзя: балансы не сходятся, переводы не оставляют следов, ответы статичные или ошибочные.

На пятом юбилейном API-хакатоне мы решили сделать иначе – собрать песочницу, которая ведёт себя как настоящий банк. Даже не один, а содружество трёх банков с клиентами, продуктами и межбанковскими сценариями. В результате появились реальные мультибанковские прототипы и ~1.5 млн вызовов API за месяц.

Меня зовут Александр Галкин, я занимаюсь открытым банкингом и открытыми API. В статье расскажу, как за несколько выходных собрать такую инфраструктуру, какие компромиссы неизбежны, почему на стенд обрушились массовые атаки, и как ИИ-ассистенты меняют сами хакатоны.

Сравниваем REST и SOAP : чем отличаются эти подходы, как они работают и почему сегодня все еще чаще выбирают REST, а не SOAP.

Привет! Эта статья - текстовая версия моего стрима с разбором задачи на бесконечную ленту по System Design.

Рассмотрим классическую задачу из System Design интервью - персональная лента подписок. По сути, мы проектируем упрощённый клон Instagram. Сама задача звучит следующим образом:

Заходишь на Хабр.Карьеру, открываешь вакансии системных аналитиков, а в требованиях всё как обычно: построение информационных систем, понимание архитектуры, ТЗ, BPMN, базовый SQL. Нигде ни слова о знании GPT или умении промптить. Формально профессия как будто не изменилась. 

Тем временем в свежем отчёте OpenAI о корпоративном применении ИИ опубликовали статистику: использование ChatGPT в корпоративной среде за год выросло в 8 раз, а объём запросов от одного человека — в среднем на 30%.

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

Это было интересное приключение.

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

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

Буду благодарен за конструктивную критику — особенно за идеи, которые помогут сделать инструмент полезнее.

Многие думают, что большие компании не совершают ошибки. Но даже если у вас налажен процесс код‑ревью и всё тщательно проверяется, риск накосячить никогда не равен нулю. Хотя, конечно, всегда лучше учиться на чужих ошибках, чем на своих.

Меня зовут Юрий Беглецов, я технический продакт в Точка Банк. Мы с командой делаем универсальные API, чтобы клиенты могли интегрировать банк и дочерние сервисы прямо в свои системы. Иногда у нас тоже бывают провалы — обидные, серьёзные и даже забавные. Две истории из серии «никогда больше» — под катом.