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

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, готовым к применению, а также примерами из практики.

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

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

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

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

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

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

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

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

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

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

Практика — лучший способ глубокого понимания теории. Рассмотрим на примере, как работают веб-сервисы с протоколом SOAP, для чего нужен WSDL и как он связан с XML-документом в теле POST-запроса.

Привет, Хабр! Меня зовут Илья Волынкин, я CTO платформы МТС Exolve. Когда мы говорим про VoIP-телефонию, первая ассоциация — Asterisk. Это open-source ПО захватило рынок и его аналоги не так популярны. На True Tech Day я рассказал про наш опыт с FreeSwitch — инструментом, решающим гораздо более масштабные задачи. 

Благодаря ему мы смогли построить платформу, которая позволяет реализовывать сложные сценарии, добавлять разные модули (например, с AI под капотом), и собирать себе системы телефонии по принципу Lego. Под катом: рассказ про то, как сейчас усложнилась инфраструктура для звонков, какие есть варианты реализации VoIP и как это может развиться в будущем. 

Краткий разбор моего опыта обучения на Яндекс.Практикуме и как я решил поменять свою жизнь и выбрать другую дорогу личностного и профессионального развития.

Мне кажется, что уже есть сотни разных статей на эту тему, но каждый раз мне чего-то не хватало. Поэтому я решил написать свою статью, в которой покажу, как я реализую авторизацию и аутентификацию в своих проектах. Это именно гайд: вы можете взять готовый код и адаптировать его под свои нужды. В рамках статьи будут использоваться Ory Hydra и Ory Kratos, Apache APISIX в качестве API Gateway и несколько микросервисов на Golang. Всё это будет работать в Docker, чтобы вы могли легко запустить и поиграться.

Так почему же Contract First оказался не так хорош на практике?

Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.

В этой статье мы расскажем, как создать собственного Telegram-бота, который интегрируется с amoCRM и распределяет уведомления о событиях в CRM, в зависимости от ролей пользователей. Система позволяет сотрудникам получать уведомления в том формате, который соответствует их обязанностям: отдел продаж видит сумму сделки и стадию, администраторы получают подробную информацию, а обычные пользователи – краткое сообщение о новой сделке. Такой подход способствует сокращению времени реакции на новые лиды, упрощает контроль за сделками и снижает необходимость постоянного ручного мониторинга CRM-системы.

Наш пример будет состоять из двух приложений. Базы данных PostgreSQL и скрипта бота.

Хорошо спроектированные и качественно документированные API — это удовольствие в работе.

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

Я, думаю, многие уже слышали о появившихся в .NET 6 Minimal API - легковесной замене контроллеров/MVC. Кто-то уже успел ознакомиться и задался вопросом: "Ваше API в 3 строчки, это, конечно, здорово, но как это будет работать в реальном проекте с сотнями эндпоинтов, кучей фильтров, аттрибутов, расширениями OpenAPI/Swagger и прочих радостях?"

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

А забегая чуть вперед: если думаете, стоит ли переводить проект на Mini API, вот вам сразу полезная информация: они могут жить в проекте вместе, причем даже без дублирования инфраструктуры: не обязательно переводить все разом - подробнее под катом.

Бонусом, заменим SwaggerGen на реализацию OpenAPI от Microsoft.

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

Друзья, привет! Меня зовут Ларионов Александр. Я работаю системным аналитиком. Совместно с Лабораторией инноваций Московской биржи мы изучали вопрос применения AI в системном анализе.

Когда я впервые столкнулся с задачей внедрения AI-ассистентов в процессы работы системного аналитика, то отреагировал скептически. Поводов было немало: большинство материалов на эту тему представляли собой восторженные отзывы вроде «AI автоматизирует рутину» или «machine learning улучшает принятие решений». Однако, при ближайшем рассмотрении, эти фразы распадались на абстрактные утверждения. Попытки уточнить у авторов конкретные кейсы или сценарии применения их инструментов для системного анализа сводились к общим фразам: «Обучите модель на ваших данных — и она всё поймёт».

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

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

Простой вопрос: делая задачу, касающуюся API - вы чаще работаете с одним эндпоинтом, или пишете, условные, репозитории, которые используются сразу в нескольких эндпоинтах? Скорее всего, первое, тогда почему мы разбиваем проект по слоям, а не по фичам (эндпоинтам)?

Это видно в часто используемых нынче архитектурных подходах: Layered, Clean Architecture, Onion, и так далее. Не буду выделять что-то конкретное и объясню общую разницу в подходах:
Vertical Slice Architecture (VSA) строится вокруг каждого отдельного feature-слайса (эндпоинта, как самый простой пример), а не вокруг слоев.

То есть, если код относится к конкретному эндпоинту, мы не размазываем его по всему проекту в папках Commands/Services/Repositories/DTOs и т.п., а кладем в одно место, там где и будет находиться эндпоинт

Главный принцип - уменьшаем связанность между слайсами (фичами), увеличиваем связанность внутри слайса

В пригороде далекого города Нью-Дели жил простой индийский паренек со сложным именем Чандракант. Любил он маму, Кришну и общаться с волшебными говорящими грибами.

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

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

А вы никогда не задумывались, почему, с одной стороны, у нас появляются всё более крутые и мощные инструменты для разработки? На бэкенде мы можем делать микросервисы, писать офигительные SPA-приложения — но при этом будто бы сама программа становится всё хуже и хуже.

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

Откуда берётся эта эрозия программного обеспечения? Почему так выходит, что новые технологии не только не помогают, но иногда даже мешают нам писать качественные программы? Почему, когда мы стараемся делать хорошо — получается плохо?
И главное — что с этим делать?