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

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

В последнее время все больше разработчиков экспериментируют с большими языковыми моделями. GigaChat от Сбера — одна из самых доступных и мощных моделей на российском рынке. У нее есть подробное REST API, которое позволяет интегрировать нейросеть в любой продукт: от телеграм-ботов до сложных корпоративных систем.

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

Я столкнулся с этими задачами и, чтобы упростить жизнь себе и другим Go-разработчикам, написал gigago — легковесный и идиоматичный SDK. Его цель — взять на себя всю "грязную работу" и позволить вам добавить GigaChat в проект буквально за несколько минут.

Excel - главный рабочий инструмент многих частных инвесторов. Здесь ведут портфели, стратегии и мониторинг котировок. Но получить от Московской биржи лучшие цены на покупку (BID) и продажу (OFFER) из стакана прямо в таблицу - задача не из простых. Даже платная подписка на сайт биржи не даёт получать котировки в Excel напрямую.

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

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

Фактически по такой схеме можно получать любые параметры с биржи и видеть их в своём локальном Microsoft Excel или его свободном аналоге LibreOffice Calc.

Весь код представлен на GitHub.

Как понять, что API отработало корректно? Как убедиться, что в ответе пришли нужные данные? И как использовать эти данные в следующих шагах, выстраивая сложные тестовые цепочки?

Именно здесь на сцену выходят post-response скрипты. Это код, который выполняется после получения ответа от сервера. Его основная задача – анализ, валидация и обработка полученных данных. Эти скрипты – ваши глаза и уши в мире API-тестирования, позволяющие автоматически проверять всё: от статус-кода до мельчайших деталей в теле JSON.

В этой статье мы рассмотрим 10 самых полезных post-response скриптов, которые превратят ручную проверку ответов в быстрый и надежный автоматизированный процесс. Давайте завершим наш путь к эффективному тестированию API!

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

Сравнение PyBind11 vs ctypes

В принципе, можно вызывать C++ из Python двумя способами: при помощи библиотеки PyBind11 для C++, которая готовит модуль Python, либо при помощи пакета cytpes для Python, который предоставляет доступ к скомпилированной разделяемой библиотеке. Работая с PyBind11, не составляет труда совместно использовать множество типов данных, в то время как ctypes — это гораздо более низкоуровневое решение в стиле C.

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

К счастью, вызывать C++ из Python не так сложно, как может показаться на первый взгляд. Таким образом, можно в какой-то степени позаимствовать интерактивность Python при разработке кода C++.

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

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

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

Как старейший «серверный» язык справляется с XXI веком, где безопасность и гибкость важнее вечной стабильности?

Разработка с помощью AI‑инструментов меняет подход к созданию ПО. Я сам убедился в этом на практике: всего за два дня мне удалось создать Text Extract API для RAG, используя Claude 4.0, Gemini Pro 2.5 и IDE Cursor. Этот эксперимент показал, что нейросети — уже не просто хайп, а мощный ассистент, способный значительно ускорить процесс разработки.

Наша команда занимается созданием ПО для IT‑специалистов — программу Управление IT‑отделом 8. В ней есть блок для работы с заявками от клиентов и обширная база знаний. Возникла идея: интегрировать нейросети для автоматической обработки тикетов. Кейс прост:

Прилетает тикет от клиента > Нейросеть смотрит в базу знаний и готовит ответ > IT‑специалист либо использует ответ нейросети, либо нейросеть отвечает автоматически.

Для реализации такого функционала необходимо обучить AI‑модель на нашей базе знаний, а это требует качественного извлечения текста из различных документов. Эта статья посвящена первому этапу этого процесса — созданию API для извлечения текстовых данных из файлов любых форматов, что критически важно для эффективной работы с Retrieval‑Augmented Generation (RAG).

Этот коротки чек-лист поможет вам структурированно отвечать на вопросы по расчету нагрузки и стоимости системы на собеседовании System Design. Используйте его как пошаговый гайд, чтобы не упустить ключевые моменты.

При проектировании систем, обязательным этапом является расчет нагрузки и стоимости на вашу IT-Систему. Давайте разберемся что это за этап и почему он так важен. А также вместе посчитаем основные показатели нагрузки и договоримся о стоимости решения.

Собеседование по System Design — это не просто проверка технических знаний, а настоящее испытание вашего инженерного мышления. В отличие от алгоритмических задач, где есть чёткие правильные и неправильные ответы, здесь всё строится на умении анализировать, взвешивать компромиссы и предвидеть проблемы до их появления. Ирония в том, что даже опытные разработчики часто проваливают эти собеседования, потому что сосредотачиваются не на том. Они могут идеально знать, как работает Kafka или Cassandra, но если не умеют структурировать свои мысли и задавать правильные вопросы, их шансы резко падают.

DevOps съел архитектора? Как тикеты убили системное мышление

Вы узнаете:
🔻 Почему техдолг - не баг, а финансовый дериватив (модель ΔProfit = -€14.3M)
🔻 3 реальных коллапса: AWS S3, Facebook DNS, Cloudflare BGP - и что их объединяет
🔻 Как техлиду внедрить архитектурный фаервол без ссор с продактом (практика Netflix/Google)
🔻 Почему "карта глубины" важнее KPI релизов (и где взять 15% времени на рефакторинг)

"Когда стоимость ошибки падает - исчезает инженер. Но щелчок предохранителя всегда громче, чем тикет"

Или как я научился не беспокоиться из-за cudaGetLastError() и просто признал её нежелательной

Если вы ежедневно работаете с API-тестированием и используете Postman, то наверняка сталкиваетесь с повторяющимися задачами: ручное получение и обновление токенов авторизации, изменение параметров запросов для разных сред разработки, копирование данных из ответов для использования в следующих запросах. Эта рутина отнимает время и силы, а также увеличивает вероятность ошибок. Что если большую часть этих действий можно автоматизировать?

В этой серии из двух статей мы пошагово разберем 10 самых полезных pre-request и 10 post-request скриптов, которые, по моему опыту, являются наиболее востребованными при тестировании API, особенно для начинающих QA инженеров. В этой и следующей статьях выполнено ранжирование этих скриптов по их важности и частоте использования, чтобы вы могли сразу осваивать и применять на практике самые необходимые из них. Каждый из 20 скриптов будет сопровождаться простым, понятным примером кода на JavaScript, готовым к применению, а также примерами из практики.

В System Design нет «правильных» решений — только компромиссы. Бюджет, сроки, команда и законы диктуют, какие технологии выбрать, как масштабироваться и когда идти на жертвы. Разберём, почему определение бизнес-ограничений это важный этап System Design и почему они диктуют Айтишникам как и с чем работать.

В этой статье:

Расскажу, как работает метод перелива веса с Wikipedia через редирект.

Разберу готовый Python-скрипт для автоматического поиска таких доменов.

Дам рекомендации по дальнейшей работе с найденными доменами.

Если на собеседовании по System Design не уделить внимание требованиям, это почти гарантированно приведёт к провалу — даже если ваше техническое решение идеально. Игнорирование требований — главная причина провала на собеседовании. Уделите этому 5-10 минут, и ваше решение сразу станет в разы сильнее. Расскажем, как собрать и зафиксировать требования чтобы повысить свои шансы при прохождении собеседования в IT-компанию.

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

Поэтому решил собрать здесь всё, что узнал — чтобы и у тех, кто столкнется с этим, процесс прошёл безболезненнее и самому через следующие 7 лет обратиться к рабочему (на данный момент😃) способу и понять, изменилось ли что-то.

Для каждого пункта выведена рабочая рекомендация

В быстро меняющемся мире веб-разработки постоянно появляются новые технологии и подходы к созданию системы обмена данными между приложением или сервисом. Одной из таких технологий, позволяющей запрашивать только необходимые данные, является GraphQL. Меня зовут Дмитрий и я python-разработчик. В этом материале я дам сравнительный обзор на REST и GraphQL.

Один из наиболее популярных примеров использования GraphQL — это применение в социальных сетях, где множество пользователей связаны между собой определёнными отношениями. К GraphQL мы прибегаем, когда нам требуется избирательно получить много данных о них. Такая организация пользователей имеет сетевую модель и представляется в виде графа, отсюда и связь с названием GraphQL (Graph — граф, QL — язык запросов).

Итак, почему компании, однажды выбравшие GraphQL, решают изменить свой курс и вернуться к стандартному способу реализации систем? Ответ на этот вопрос лежит на пересечении технических возможностей, бизнес-потребностей и экономических соображений. Давайте разберёмся в этом подробнее.