Backend и проектирование API
Все объяснения, задачи и лабораторная в одном месте.
Можно сохранить страницу в PDF через печать браузера. Для печати разборы ответов раскрываются автоматически.
1. HTTP semantics и ресурсная модель
Объяснение
HTTP-ресурс имеет идентификатор, представление и допустимые операции. GET не должен менять бизнес-состояние. Статус описывает результат запроса, а тело ошибки помогает клиенту исправить проблему.
Задача для самостоятельного решения
Как ответить на создание заказа?
Показать разбор ответа
После успешного создания вернуть 201 и Location ресурса. Неверный ввод требует согласованного 4xx-ответа; внутренний сбой не нужно выдавать за ошибку пользователя.
2. Валидация, ошибки и идемпотентность
Объяснение
Идемпотентность означает одинаковый эффект повторного выполнения, а не одинаковый ответ. Для POST-платежа ключ повторной операции связывают с параметрами и результатом. Валидация должна происходить до побочных эффектов.
Задача для самостоятельного решения
Один ключ пришёл с двумя разными суммами. Что делать?
Показать разбор ответа
Отклонить конфликт: ключ идентифицирует конкретную операцию, а не разрешает менять её смысл. Сохранение ключа и бизнес-эффекта должно быть согласовано транзакционно.
3. Аутентификация, авторизация и сессии
Объяснение
Аутентификация устанавливает личность; авторизация разрешает действие над конкретным объектом. Сессия должна иметь срок и защищённую cookie. Проверка роли без проверки владельца создаёт утечку чужих данных.
Задача для самостоятельного решения
Пользователь меняет /orders/10 на /orders/11. Где защита?
Показать разбор ответа
Сервер проверяет доступ к заказу 11 при каждом запросе. Скрытая ссылка в интерфейсе не является контролем доступа.
4. Транзакции, кеш и фоновые задачи
Объяснение
Транзакция защищает связанные записи, но не охватывает произвольный HTTP-вызов. Outbox сохраняет намерение отправить событие вместе с изменением БД. Кеш требует понятного срока и способа обновления.
Задача для самостоятельного решения
Как не потерять событие после COMMIT заказа?
Показать разбор ответа
В той же транзакции записать событие в outbox. Worker доставляет его повторяемо, получатель дедуплицирует. Отправка после COMMIT без outbox имеет окно потери.
5. OpenAPI, compatibility и versioning
Объяснение
Контракт API определяет обязательные поля, типы, ошибки и совместимость. Добавление обязательного поля ломает старых клиентов. Версия нужна при несовместимом изменении, а не при каждой внутренней правке.
Задача для самостоятельного решения
Можно ли переименовать поле price в amount без перехода?
Показать разбор ответа
Старые клиенты перестанут читать цену. Сохраните старое поле на переходный период либо выпустите новую версию с явной политикой отключения старой.
6. Наблюдаемость, нагрузка и graceful degradation
Объяснение
Метрики показывают частоту и задержки, логи — события, traces — путь через зависимости. Ограничение очереди предотвращает бесконечное накопление работы. Graceful degradation допускает частичную пользу при сбое зависимости.
Задача для самостоятельного решения
Рекомендации недоступны. Должна ли падать карточка товара?
Показать разбор ответа
Если рекомендации необязательны, вернуть карточку без них с коротким timeout. Отдельно учитывать ошибки рекомендаций, чтобы деградация не скрывала неисправность.
Лабораторная работа
Подготовка
Самодостаточный контракт учебного API; блок ниже — HTTP-пример, а не shell-команды.
Учебный пример
POST /orders HTTP/1.1
Content-Type: application/json
Idempotency-Key: example-order-001
{"items":[{"product_id":1,"quantity":2}]}
HTTP/1.1 201 Created
Location: /orders/42
Content-Type: application/json
{"id":42,"status":"created"}Как работает пример и что ожидать
Цена определяется сервером по product_id, а не принимается без проверки от клиента. Повтор того же ключа и тела должен возвращать результат той же операции; другой payload с тем же ключом — конфликт. Проверка владельца нужна и для последующего GET /orders/42.
Итоговая работа
Реализуйте API с БД, схемой ошибок и объектной авторизацией. Включите в документацию 400/401/403/404/409, повторы и ограничения. Тестируйте потерянный ответ после сохранения заказа и параллельный запрос с тем же ключом.
Проверка результата
1. Опишите исходные данные и условия запуска, чтобы другой человек мог повторить работу.
2. Приложите результат обычного сценария и сравните его с ожидаемым.
3. Проверьте неверный вход, граничный случай и отказ зависимости, если она есть.
4. Объясните выбранное решение и известное ограничение.
5. Сохраните исправления после самопроверки вместе с примером, который раньше не работал.
Как оценить работу
По каждому пункту поставьте 0 (не выполнено), 1 (выполнено с пробелами) или 2 (результат воспроизводим и объяснён). Если обязательный сценарий не работает, вернитесь к нему независимо от общей суммы. Это рубрика самопроверки: сайт не исполняет присланный код и не выдаёт автоматическую оценку проекта.