API и протоколы

Аналитик редко пишет код, но постоянно пишет контракты — как две системы обменяются данными по HTTP. Чтобы контракт не развалился на проде, нужно точно знать, из чего состоит запрос и ответ, что означает класс кода состояния, какой метод безопасно повторять, а какой создаст дубль.

Здесь собраны основы, на которых держится любая спецификация API. Заранее назовём ловушки: REST путают с протоколом, POST считают идемпотентным, XSD приписывают описание JSON, а класс 4xx меняют местами с 5xx. Каждая из них — типичный провал на собеседовании. Полная карта — в слоях ниже.

Карта темы

• Протокол HTTP — из чего состоят запрос и ответ и что означают пять классов кодов состояния.
• HTTP-методы — чем различаются GET, POST, PUT, PATCH по осям чтение/запись и идемпотентность.
• Идемпотентность — почему повтор создаёт дубли и как ключ идемпотентности их гасит.
• Принципы REST — REST как архитектурный стиль поверх HTTP и его ограничения.
• Стили API — сравнение SOAP, REST, gRPC и GraphQL и где какой уместен.
• Форматы данных — JSON, YAML, XML и их схемы (XSD, json-schema, WSDL).

Частые ошибки и ловушки

Значение для собеседований

Тему спрашивают, чтобы проверить, отличаете ли вы контракт от реализации и умеете ли рассуждать о надёжности обмена. Кандидат, который объясняет идемпотентность через «уникальный ключ делает N одинаковых запросов эффектом одного», сразу опережает «ну, это когда запрос можно повторять».

Что обычно проверяют:

• Структуру HTTP-сообщения и смысл классов кодов (4xx — клиент, 5xx — сервер).
• Разницу PUT (полная замена, идемпотентен) и PATCH (частичное изменение) и почему POST не идемпотентен.
• Что REST — стиль, а не протокол, и его ключевые ограничения.
• Когда предпочесть gRPC или GraphQL и что описывают XSD/WSDL/json-schema.

Типичный неверный ответ: «REST — это протокол вроде SOAP, только легче». На самом деле REST — набор рекомендаций поверх HTTP; реальные API соблюдают его ограничения в разной степени, а строгий контракт с WSDL — это как раз про SOAP.