Расскажите про опыт работы с API, REST и SOAP
Что проверяют
Понимаете ли вы, чем отличаются два подхода к интеграции, и умеете ли тестировать сервис ниже интерфейса. Разговор быстро уходит в практику: что именно вы проверяли в запросах и ответах.
Как отвечать
Коротко про суть, дальше про проверки. REST это стиль поверх HTTP: ресурсы в адресах, смысл операции в методе и коде ответа, тело обычно в JSON, контракт описывают в OpenAPI. SOAP это протокол обмена XML-сообщениями в конверте, контракт задаёт WSDL со схемой, ошибка приходит отдельным элементом Fault, вокруг есть стандарты безопасности и транзакций.
Для тестировщика разница практическая: в SOAP схема строгая, и часть проверок сводится к валидации по ней. В REST контракт держится на договорённостях, поэтому расхождение реализации и спецификации это самый частый дефект.
Что стоит назвать своими проверками:
- коды ответа под каждый сценарий: 200, 201, 400, 401, 403, 404, 409, 422, 500;
- обязательные и необязательные поля, типы, границы, пустые значения, длинные строки, кодировка;
- доступ: чужой объект по прямому идентификатору, просроченный токен, отсутствующий заголовок;
- повторный вызов: появляются ли дубликаты, идемпотентен ли метод;
- поведение при недоступной зависимости и при таймауте;
- состояние в базе после вызова, а не только тело ответа.
Инструменты называйте вместе с задачей: curl и Postman для ручных проверок, SoapUI для SOAP, автотесты, заглушки вместо смежных сервисов.
Где спотыкаются
Сводят разницу к формату: якобы REST это JSON, а SOAP это XML. REST спокойно отдаёт XML, а отличие SOAP в контракте, конверте и наборе стандартов вокруг него.
Второе: проверяют только счастливый путь. Код 200 и непустое тело ещё не значат, что запись создалась, права проверены, а повтор не породил дубль.
Третье: путают транспорт и бизнес-результат. Ответ приходит с кодом 200, а внутри отказ; в SOAP элемент Fault внутри успешного HTTP-ответа это норма. Проверять нужно и код, и содержимое, и то, что осталось в системе.