Как устроен XML в SOAP запросах?
Что проверяют
Понимаете ли вы структуру SOAP-сообщения настолько, чтобы собрать запрос руками и прочитать ошибку. Следом обычно спрашивают, где взять описание операций и чем отличаются версии SOAP 1.1 и 1.2.
Как отвечать
SOAP-сообщение это XML-документ с жёсткой обёрткой:
Envelope: корневой элемент. По его пространству имён определяется версия:http://schemas.xmlsoap.org/soap/envelope/у SOAP 1.1 иhttp://www.w3.org/2003/05/soap-envelopeу SOAP 1.2. Конверт чужой версии сервер отклонит;Header: необязательный, в нём служебные данные: токены WS-Security, идентификаторы транзакций, адресация. Элемент с атрибутомmustUnderstandсервер обязан обработать или вернуть ошибку;Body: обязательный, внутри элемент операции с параметрами в пространстве имён сервиса;Fault: не отдельный раздел запроса, а элемент внутриBodyответа, когда что-то пошло не так. В 1.1 этоfaultcode,faultstring,detail, в 1.2Code,Reason,Detail. HTTP-статус при этом обычно 500, в SOAP 1.2 для ошибки на стороне клиента допускается 400.
Контракт описан в WSDL: операции, адрес, привязка, а типы данных задаёт XSD-схема. SoapUI по WSDL сам генерирует шаблоны запросов; в Postman запрос собирают руками как raw XML.
Отличия на уровне HTTP тоже спрашивают: SOAP 1.1 идёт с Content-Type: text/xml и заголовком SOAPAction, SOAP 1.2 с application/soap+xml, где действие передаётся параметром action.
Для тестировщика отсюда чек-лист: валидность по XSD, обязательные поля, типы и граничные значения, экранирование & и < в строках, корректный Fault на неверный ввод. В SoapUI ответ удобно проверять через XPath-ассерты.
Где спотыкаются
Считают префикс soap: значимым. Сервер смотрит на URI пространства имён, префикс может быть любым, а правильный префикс с неверным URI не сработает.
Рисуют Fault рядом с Body в запросе. Он приходит только в ответе и только внутри Body.
Проверяют ответ сравнением строк. Порядок атрибутов, пробелы и префиксы могут меняться без изменения смысла, поэтому надёжнее XPath и валидация по схеме.