Зачем это спрашивают
Этот вопрос проверяет широту кругозора. Большинство современных веб-продуктов используют REST, но в банках, страховании и интеграциях с государственными системами до сих пор работают SOAP-сервисы, а многие фронтенды получают данные через GraphQL. Интервьюеру важно понять, не растеряетесь ли вы, если на проекте окажется не привычный JSON по адресам /orders/7, а XML-конверт или один адрес /graphql на всё.
Часто вопрос начинается шагом раньше: «что такое API». Начните с этого определения — так ответ получится цельным.
Как построить сильный ответ
Что такое API
API — договорённость о том, как одна программа обращается к другой: какие запросы можно отправить, в каком формате и что вернётся в ответ. Пользователь работает с интерфейсом, а интерфейс, мобильное приложение или другой сервис — с API.
Три подхода
REST — архитектурный стиль поверх HTTP. Адрес обозначает ресурс, метод — действие над ним, данные чаще всего в JSON. Сервер не хранит состояние клиента между запросами: каждый запрос несёт всё нужное, включая токен. Ошибки выражаются кодами ответа HTTP. Контракт обычно описывают в OpenAPI, и по нему строится Swagger.
GET /api/orders/7 HTTP/1.1
Authorization: Bearer <токен>
SOAP — протокол обмена XML-сообщениями. Каждое сообщение — конверт Envelope с необязательным Header и обязательным Body; ошибка передаётся элементом Fault. Контракт описан в WSDL — машиночитаемом документе со всеми операциями и типами. Чаще всего SOAP ходит по HTTP методом POST на один адрес, а нужная операция указана внутри XML. Есть стандарты для подписи и шифрования сообщений, поэтому SOAP прижился там, где важны строгий контракт и формальные требования к безопасности.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Body>
<GetOrder><OrderId>7</OrderId></GetOrder>
</soap:Body>
</soap:Envelope>
GraphQL — язык запросов к API. Обычно один адрес, клиент сам перечисляет, какие поля ему нужны, и получает ровно их. Схема типов строгая, есть запросы на чтение (query), изменения (mutation) и подписки (subscription). Это решает две проблемы REST: лишние данные в ответе и необходимость дёргать несколько эндпоинтов ради одного экрана.
query {
order(id: 7) { id status items { title qty } }
}
Сравнение
| REST | SOAP | GraphQL | |
|---|---|---|---|
| Что это | стиль | протокол | язык запросов |
| Формат | обычно JSON | только XML | JSON в ответе |
| Адреса | много, по ресурсам | обычно один | обычно один |
| Контракт | OpenAPI, если описан | WSDL, обязателен | схема, обязательна |
| Ошибки | коды HTTP | элемент Fault | поле errors, часто при 200 |
Что это значит для тестирования
- В REST много внимания методам, кодам, идемпотентности и правам на каждый ресурс.
- В SOAP проверяете соответствие XML схеме, обязательные элементы, пространства имён и содержимое
Fault. - В GraphQL — не только успешные запросы, но и запрос несуществующего поля, слишком глубоко вложенный запрос, доступ к полям, которые роль видеть не должна. И помните: статус 200 ещё не значит успех.
Пример ответа
API — это договорённость, как программы обмениваются данными. REST — архитектурный стиль поверх HTTP: ресурсы в адресах, действия задаются методами, данные обычно в JSON, сервер не хранит состояние клиента, ошибки передаются кодами ответа. SOAP — строгий протокол: сообщения только в XML, в конверте, контракт описан в WSDL, обычно все запросы идут POST на один адрес. Его часто встречаю в банковских и государственных интеграциях. GraphQL — язык запросов: один адрес, клиент сам выбирает нужные поля, есть строгая схема. Для тестирования разница заметная: в REST я проверяю коды и методы, в SOAP — соответствие XML схеме и Fault, а в GraphQL смотрю поле errors, потому что ошибка может прийти со статусом 200.
Частые ошибки
- Называть REST протоколом или говорить, что REST — это «когда JSON».
- Считать SOAP устаревшим и поэтому неважным. Он жив там, где интеграции годами не меняют.
- Говорить, что GraphQL «заменил REST». Это разные инструменты под разные задачи.
- Определять API как «сайт для программистов» без слов о контракте, запросе и ответе.
- Перечислять отличия без единого вывода о том, как меняются проверки.
Пример на MarketCove
API учебного магазина MarketCove построен в стиле REST, и на нём удобно показать признаки стиля. Откройте Swagger на /api/docs:
- ресурсы названы существительными:
/api/products,/api/products/{id},/api/orders; - действие задаёт метод, а не адрес: список товаров и конкретный товар получают через GET;
- сервер узнаёт пользователя по токену в каждом запросе к
/api/users/me, а не по «сессии в памяти» между вызовами.
Мысленный эксперимент для собеседования: как выглядела бы карточка товара, если бы магазин работал на GraphQL? Один запрос product(id: 3) { title price } вместо полного объекта. Какие проверки добавились бы? Например, запрос поля, которого нет в схеме, и попытка запросить у товара данные, которые покупателю видеть не положено. Такое рассуждение показывает, что вы понимаете подходы, а не только их определения.
Задание для практики
Выберите один эндпоинт магазина, например получение товара по id, и опишите его тремя способами: REST-запросом, SOAP-конвертом и GraphQL-запросом. Для каждого запишите, как будет выглядеть ошибка «товар не найден». Затем проверьте REST-вариант в API-песочнице и сравните реальный ответ с вашим ожиданием. Чтобы закрепить связанные темы, повторите HTTP-методы и чек-лист тестирования API.
