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

Основная часть работы современных разработчиков ПО¹ связана с API: публичными интерфейсами для общения с программой, например, API Twilio. Я потратил кучу времени на работу с API как их разработчик и пользователь. Я писал публичные API для сторонних разработчиков, приватные API для внутреннего использования (или для потребления одной страницей фронтенда), API REST и GraphQL и даже несетевые интерфейсы, например, для инструментов командной строки.

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

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

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

В данной публикации я хотел бы рассказать про самые важные стадии жизненного цикла API, а также по каждому этапу добавить интересные статистические данные, проведя анализ основных международных отчётов, таких как Postman State of Api , NordicAPIs и многих других.

Привет, Хабр! Меня зовут Евгений Лукин, я CPO продукта MWS OctAPI — это интеграционная платформа, которую мы создали для задач МТС, но теперь предлагаем как продукт на рынке.

Интеграционные платформы… кажется, что это что-то скучное и уже давно commodity —  шины данных, kafka — вот это вот всё, что тут может быть интересного?

Да, но нет.

Фича для мобилки, которая должна работать на более ранних версиях.
Как подойти к реализации и преодолеть ограничения?

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

Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.

Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре. 

Это третья статья из цикла «Проектирование GraphQL API».

В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдем к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.

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

Привет, Хабр! Меня зовут Ваня, и я AQA-инженер. Как и многие из вас, я занимаюсь обучением будущих покорителей Postman и Pytest. И, как многие из вас, я столкнулся с проблемой: все существующие тестовые API — невыносимо скучные.

Todo-листы, интернет-магазины с товарами Item 1, Item 2, API для управления книгами... Серьезно? После пятого GET /todos начинаешь сомневаться не только в своей карьере, но и в смысле бытия. Данные в них стерильны, как операционная, а сценарии предсказуемы, как сюжет российского сериала.

Моим ученикам было скучно. Мне было скучно. Я понял, что нужен свой API. С блэкджеком и... ну, вы поняли. С API, который будет не просто функциональным, но и забавным. Который захочется «потыкать» просто ради того, чтобы увидеть очередной перл в ответе сервера.

Так родился «Cynical Circle API» — API для тех, кто понял жизнь и устал от ванильных примеров.

(Так выглядит наша интерактивная документация. Уже интригует, не правда ли?)

Хабр, привет! Меня зовут Елена Петренко, я бизнес-аналитик по информационной безопасности в компании R-Vision.

В прошлой статье мы подробно рассматривали интеграцию SOAR-системы с АСОИ ФинЦЕРТ для автоматизации взаимодействия с регулятором. Сегодня я расскажу, почему интеграции в целом являются ключевым элементом эффективного управления ИБ, какие бывают способы интеграции систем и рассмотрю практические кейсы интеграции SOAR с другими популярными сервисами: Telegram и Kaspersky Security Center, а также поделюсь опытом работы с АСОИ ФинЦЕРТ в более широком контексте.

Моя повседневная работа с основном связана с языком Elm. Благодаря сочетанию функционального языка и архитектуры Elm, многие архитектурные решения в нём получаются практически незаметными (подробнее об этом я рассказываю в этом посте у меня в блоге). Вы получаете четкое разделение задач, а язык по умолчанию подталкивает вас к хорошему проектированию.

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

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

Иногда JSON выглядит рабочим, но под капотом он полон сюрпризов: лишние уровни вложенности, запутанные поля и непонятные даты. Разбираем пример и доводим структуру до ума.

Если Вы когда-либо разрабатывали Telegram-бота, Вы наверняка знаете, что такое callback_data. Если нет, вкратце, это произвольная строка, которая привязывается к кнопкам в чате, при помощи которой на бэкенде Вы определяете, какая именно кнопка была нажата.

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

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

Предлагаю сегодня посмотреть на живом примере и понять могут ли нейросети заменить аналитиков?

Салют, Хабр! Меня зовут Всеволод, и я занимаюсь анализом защищенности веб-приложений в Positive Technologies.

С API веб-приложений я успел познакомиться со всех сторон: как разработчик, инженер в AppSec и пентестер. В большой корпорации мне пришлось столкнуться с колоссальными объемами API. Я быстро осознал, что в таких количествах их просто невозможно проверить вручную, и начал искать способы автоматизации. В результате уже больше двух лет я занимаюсь динамическим тестированием (DAST), в частности фаззингом.

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

Pix – это национальная система мгновенных платежей Бразилии, запущенная Центральным банком (Banco Central do Brasil, BCB) в ноябре 2020 года. Всего за несколько лет она совершила революцию в финансовой сфере страны, став повсеместно используемым способом переводов и платежей.

Pix позволяет физическим лицам, компаниям и государственным учреждениям переводить средства между любыми банками 24/7, практически мгновенно и с минимальными издержками. К 2024 году около 153 млн бразильцев (примерно 75% населения) и 15 млн компаний воспользовались Pix, а объем транзакций достиг 42 млрд в год – поразительные показатели, свидетельствующие о масштабном успехе системы. В этом обзоре мы рассмотрим архитектуру Pix, взаимодействие пользователей, банков и регулятора, вопросы безопасности и API-интерфейсов, роли участников (банки, финтехи, торговые предприятия), управление данными и отказоустойчивость системы. Отдельно постараюсь рассказать об интеграции Pix в контексте Open Banking/Open Finance и сравню Pix с другими системами быстрых платежей (индийской UPI, европейской SEPA Instant и российским СБП).

Казалось бы - все бьются над увеличением количества подписчиков в своих Telegram-каналах - зачем уменьшать их число?

Я сам заинтересовался этой темой после странного всплеска трафика. Опубликовал статью про голосовых ассистентов - и из-за неудачного заголовка она внезапно стала вирусной. Обычно мои тексты собирают около 7 тысяч просмотров (медиана), но в этот раз счётчик вырос до 140 тысяч. А до этого я уже слышал истории, как на каналы без рекламы и инфоповодов «наливаются» сотни или тысячи подписчиков. Звучит как подарок судьбы, но на практике это тревожный сигнал: чаще всего - это фейковые аккаунты.

Мёртвая аудитория - это падение вовлеченности (ER - уровень вовлеченности, ERR - вовлеченность на охват), потеря интереса со стороны рекламодателей и снижение позиций канала в поиске Telegram. Особенно сейчас, когда алгоритмы всё больше ориентируются на наличие Premium-подписчиков.

В этой статье покажу, как выявить и удалить нежелательных подписчиков с помощью open-source скрипта на Python - который работает даже несмотря на ограничения Telegram API, позволяющий получить лишь последние 200 участников.

Привет, меня зовут Павел, я являюсь разработчиком в DD Planet. Сегодня хочу поговорить об одной частой ситуации. Если ваш web сервис работает по подпискам или с регулярными платежами — рано или поздно встаёт вопрос: брать готовое решение или сделать своё.

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

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

В этой статье разбираемся с MCP-серверами от А до Я: что это такое, зачем нужны и как создать свой. Научимся писать инструменты для ИИ-агентов, подключать готовые MCP-серверы через LangGraph, и создадим полноценный математический сервер с нуля. В конце задеплоим его в облако и подключим к нейросети. Много практики, рабочий код и никакой воды — только то, что действительно работает.