Гоф Дж., Брайант Д., Оберн М. Проектирование архитектуры API. Как правильно проектировать, развивать и эксплуатировать API

Астана: Алист, 2024. — 288 с.: ил. — ISBN: 978-601-09-5053-5.Гоф Джеймс (James Gough) — заслуженный инженер в компании Morgan Stanley, Java-чемпион, соавтор книги «Optimizing Java».Дэниэл Брайант (Daniel Bryant) — глава отдела по взаимодействию с разработчиками в компании Ambassador Labs, Java-чемпион. Эксперт в инструментарии DevOps, облачных и контейнерных платформах, микросервисах.Оберн Мэтью (Matthew Auburn) — вице-президент компании Morgan Stanley. Занимался разработкой финансовых систем, мобильных и веб-приложений, обеспечением безопасности API.Фундаментальная книга о разработке и реализации API (программных интерфейсов приложений). Разобраны базовые вопросы обмена информацией в микросервисной архитектуре, обработка запросов на сайтах и в веб-приложениях (парадигма REST). Показано, как поступательно развивать имеющиеся API, не переписывая их, а также как создать API любой сложности с нуля с учетом возможностей и ограничений конкретной системы. Книга поможет реализовать на предприятии архитектуру сервисной сети и подготовить ресурсы компании к миграции в облако.Для архитекторов программного обеспечения.Вступительное слово

Предисловие
Для чего мы написали эту книгу?
Почему стоит прочитать эту книгу?
Для кого эта книга?
Разработчик
Случайный архитектор
Архитектор решений, корпоративный архитектор
Чему вы научитесь?
О чем не расскажет эта книга?
Условные обозначения
Использование примеров кода
Платформа онлайн-обучения O’Reilly
Как с нами связаться?
Благодарности
Благодарности Джеймса Гофа
Благодарности Дэниэла Брайанта
Благодарности Мэтью ОбернаВведение
Путешествие по архитектуре
Что же такое API?
Практический пример конференц-системы: запуск
Типы API в практическом примере конференции
Причины изменения конференц-системы
От многоуровневой архитектуры к моделированию API
Практический пример: эволюционный этап
Трафик север-юг
Трафик восток-запад
API-инфраструктура и шаблоны трафика
Дорожная карта для практического примера конференции
Использование диаграмм C4
Диаграмма контекста C4
Диаграмма контейнеров C4
Диаграмма компонентов C4
Использование записей архитектурных решений
ADR-запись эволюции участников
Осваиваем API: руководства ADR
ЗаключениеПроектирование, создание и тестирование APIПроектирование, создание и спецификация API
Практический пример: проектирование API Участник
Знакомство с REST
Знакомство с REST и HTTP на примере
Модель зрелости Ричардсона
Введение в API удаленного вызова процедур (RPC)
Краткое упоминание о языке GraphQL
Стандарты и структура REST API
Коллекции и пагинация
Фильтрация коллекций
Обработка ошибок
Руководство ADR: выбор стандарта API
Определение REST API с помощью OpenAPI
Практическое применение спецификаций OpenAPI
Генерация кода
Валидация OpenAPI
Примеры и создание имитаций
Обнаружение изменений
Версионирование API
Семантическое версионирование
Спецификация и версионирование OpenAPI
Реализация RPC с помощью gRPC
Моделирование обмена данными и выбор формата API
Сервисы с высоким уровнем трафика
Большие полезные нагрузки при обмене данными
Преимущества производительности HTTP/2
Старые форматы
Рекомендация: моделирование обменов
Различные спецификации
Существует ли «золотая спецификация»?
Проблемы комбинированных спецификаций
ЗаключениеТестирование API
Сценарий конференц-системы для этой главы
Стратегии тестирования
Тестовый квадрант
Тестовая пирамида
Руководство ADR по стратегиям тестирования
Контрактное тестирование
Почему часто предпочтительнее проводить контрактное тестирование
Порядок реализации контракта
Контракты производителя
Контракты, ориентированные на потребителя
Наш пример: использование CDC
Обзор методологии контрактов
Фреймворки для контрактного тестирования
Хранение и публикация контрактов API
Руководство ADR: контрактное тестирование
Тестирование компонентов API
Контрактное тестирование в сравнении с тестированием компонентов
Практический пример: тестирование компонентов для проверки поведения
Интеграционное тестирование API
Использование серверов-заглушек: почему и как?
Руководство ADR: интеграционное тестирование
Контейнеризация тестовых компонентов: Testcontainers
Практический пример: применение Testcontainers для верификации интеграций
Сквозное тестирование
Автоматизация сквозной валидации
Типы сквозных тестов
Руководство ADR: сквозное тестирование
ЗаключениеУправление трафиком APIAPI-шлюзы: управление входящим трафиком
Является ли API-шлюз единственным решением?
Рекомендация: прокси, балансировщик нагрузки или API-шлюз
Практический пример: открытие доступа к сервису Участник для потребителей
Что такое API-шлюз?
Какие функциональные возможности предоставляет API-шлюз?
Где выполняется развертывание API-шлюза?
Как API-шлюз интегрируется с другими технологиями на периферии?
Зачем нужен API-шлюз?
Снижение связанности: адаптер/фасад между фронтендами и бэкендами
Упрощение использования: агрегирование/преобразование бэкенд-сервисов
Защита API от чрезмерного использования и злоупотреблений: обнаружение и устранение угроз
Понимание того, как используются API: наблюдаемость
Управление API как продуктами: менеджмент жизненного цикла API
Монетизация API: управление учетными записями, биллинг и оплата
Современная история API-шлюзов
1990-е годы и далее: аппаратные балансировщики нагрузки
Начало 2000-х годов и далее: программные балансировщики нагрузки
Середина 2000-х: контроллеры доставки приложений (ADC)
Начало 2010-х: API-шлюзы первого поколения
2015 год и далее: API-шлюзы второго поколения
Текущая таксономия API-шлюзов
Традиционные корпоративные шлюзы
Микросервисы/микрошлюзы
Шлюзы сервисных сетей
Сравнение типов API-шлюзов
Практический пример: развитие конференц-системы с помощью API-шлюза
Установка Ambassador Edge Stack в Kubernetes
Настройка сопоставления URL-путей с бэкенд-сервисами
Настройка сопоставлений с использованием маршрутизации на основе хостов
Развертывание API-шлюзов: понимание и управление отказами
API-шлюз как единая точка отказа
Обнаружение и принадлежность проблем
Разрешение инцидентов и проблем
Снижение рисков
Общие ошибки при внедрении API-шлюзов
Loopback API-шлюза
Шлюз API в качестве корпоративной сервисной шины (ESB, Enterprise Service Bus)
Черепахи (API-шлюзы) — и нет им конца
Выбор API-шлюза
Определение требований
Создание или покупка?
Руководство ADR: выбор API-шлюза
ЗаключениеСервисные сети: управление трафиком между сервисами
Сервисная сеть — это единственное решение?
Рекомендация: стоит ли внедрять технологию сервисной сети?
Практический пример: извлечение функциональности сессий в сервис
Что такое сервисная сеть?
Какие функциональные возможности предоставляет сервисная сеть?
Где развертывается сервисная сеть?
Как сервисная сеть интегрируется с другими сетевыми технологиями?
Зачем нужна сервисная сеть?
Тонкий контроль маршрутизации, надежности и управления трафиком
Прозрачная маршрутизация и нормализация имен сервисов
Надежность
Продвинутая маршрутизация трафика: придание формы, контроль, разделение и зеркалирование
Придание формы трафику
Контроль трафика
Обеспечение прозрачной наблюдаемости
Обеспечение безопасности: транспортная безопасность, аутентификация и авторизация
Поддержка кросс-функционального взаимодействия на разных языках
Разделение управления входящим и межсервисным трафиком
Эволюция сервисных сетей
Ранняя история и мотивация
Шаблоны реализации
Библиотеки
Sidecar
Библиотеки gRPC без прокси
Без sidecar: реализации ядра операционной системы (eBPF)
Таксономия сервисных сетей
Практический пример: использование сервисной сети для маршрутизации, наблюдаемости и безопасности
Маршрутизация с помощью Istio
Наблюдение за трафиком с помощью Linkerd
Сегментация сети с помощью Consul
Развертывание сервисной сети: понимание и управление отказами
Сервисная сеть как единая точка отказа
Общие проблемы внедрения сервисной сети
Сервисная сеть в качестве ESB
Сервисная сеть в качестве шлюза
Слишком много сетевых уровней
Выбор сервисной сети
Определение требований
Создание или покупка?
Руководство ADR: выбор сервисной сети
ЗаключениеЭксплуатация и безопасность APIРазвертывание и релизы API
Отделение развертывания от релиза
Практический пример: установка флагов функций
Управление трафиком
Практический пример: моделирование релизов в конференц-системе
Жизненный цикл API
Сопоставление стратегий релизов с жизненным циклом
Руководство ADR: отделение релиза от развертывания с помощью управления трафиком и флагов функций
Стратегии релизов
Канареечный релиз
Зеркалирование трафика
Сине-зеленое развертывание
Практический пример: развертывание с помощью Argo Rollouts
Мониторинг успешного выполнения и выявление отказов
Три столпа наблюдаемости
Важные метрики для API
Считывание сигналов
Прикладные решения для эффективных релизов программного обеспечения
Кеширование ответов
Распространение заголовков на уровне приложений
Ведение журнала для помощи в отладке
Рассмотрение субъективной платформы
Руководство ADR: субъективные платформы
ЗаключениеОперационная безопасность: моделирование угроз для API
Практический пример: применение OWASP к API участников
Риск при отсутствии защиты внешних API
Моделирование угроз 101
Мыслите как злоумышленник
Как построить модель угрозы?
Этап 1: определение целей
Этап 2: сбор нужной информации
Этап 3: декомпозиция системы
Этап 4: выявление угроз и включение их в модель STRIDE
Spoofing (Спуфинг)
Tampering (Подмена)
Внедрение полезной нагрузки
Массовое переназначение
Repudiation (Отрицание)
Information disclosure (Разглашение сведений)
Чрезмерное раскрытие данных
Некорректное управление активами
Denial of Service (Отказ в обслуживании)
Ограничение количества запросов и сброс нагрузки
Elevation of privilege (Расширение полномочий)
Неправильная конфигурация безопасности
Терминирование TLS-соединений
Совместное использование ресурсов разными источниками
Усиление директив безопасности
Этап 5: Оценка рисков угроз
Этап 6: Валидация
ЗаключениеАутентификация и авторизация API
Аутентификация
Аутентификация конечных пользователей на основе токенов
Аутентификация между системами
Почему не следует смешивать ключи и пользователей?
OAuth2
Роль сервера авторизации при взаимодействии с API
Веб-токены JSON (JWT)
Кодирование и верификация веб-токенов JSON
Терминология и механизмы предоставления доступа OAuth2
Руководство ADR: стоит ли рассматривать возможность использования OAuth2?
Authorization Code Grant: предоставление доступа по коду авторизации
Authorization Code Grant (+ PKCE)
Практический пример: доступ к API Участник с помощью Authorization Code Grant
Refresh-токены
Client Credentials Grant: предоставление доступа к учетным данным клиента
Практический пример: доступ к API Участник из CFP-системы при помощи Client Credentials Grant
Дополнительные варианты предоставления доступа OAuth2
Руководство ADR: какой из грантов OAuth2 стоит поддерживать
Области видимости OAuth2
Практический пример: применение областей видимости OAuth2 к API Участник
Обеспечение выполнения авторизации
Вкратце об OIDC
Протокол SAML 2.0
ЗаключениеЭволюционная архитектура с применением APIПерепроектирование приложений на архитектуру, управляемую API
Зачем использовать API для развития системы?
Создание полезных абстракций: повышение связности
Уточнение границ домена: продвижение слабой связанности
Практический пример: установление границ домена сервиса Участник
Варианты архитектуры конечного состояния
Монолит
Сервис-ориентированная архитектура (SOA)
Микросервисы
Функции
Управление эволюционным процессом
Определите свои цели
Использование функций приспособленности
Декомпозиция системы на модули
Создание API как «швов» для расширения
Определение точек приложения усилий в системе
Непрерывная поставка и верификация
Архитектурные паттерны для эволюционирующих систем с API
Паттерн «Душитель»
Паттерны «Фасад» и «Адаптер»
Паттерн «Слоеный пирог API»
Определение болевых точек и возможностей
Вопросы модернизации и технического сопровождения
Проблемы с производительностью
Разрушение зависимостей: API с сильной связанностью
ЗаключениеИспользование инфраструктуры API для эволюции в сторону облачных платформ
Практический пример: перенос сервиса Участник в облако
Выбор стратегии миграции в облако
Сохранение или пересмотр
Перенос
Смена платформы
Новая покупка
Рефакторинг/смена архитектуры
Отключение
Практический пример: смена платформы сервиса Участник для переноса его в облако
Роль API-менеджмента
Север-юг и восток-запад: размывание границ управления трафиком
Начните с периферии и работайте вглубь
Пересекая границы: маршрутизация по сетям
От зональной архитектуры к принципу нулевого доверия
Попадание в зону
Никому не доверять и проверять
Роль сервисной сети в архитектурах с нулевым доверием
Дополнение сервисной сети сетевыми политиками
ЗаключениеПодведение итогов
Практический пример: оглянитесь на пройденный путь
API, Закон Конвея и ваша организация
Понимание типов решений
Подготовка к будущему
Асинхронное взаимодействие
Протокол HTTP/3
Сеть на основе платформы
Что дальше: как продолжать изучать архитектуру API?
Постоянное совершенствование базовых знаний
Следите за новостями в отрасли
Радары, квадранты и трендовые отчеты
Изучение лучших практик и примеров использования
Обучение на практике
Обучение через преподаваниеПредметный указатель
Об авторах
Об изображении на обложке