Работали ли вы с SOAP
Что проверяют
Аналитика спрашивают не про код, а про контракт: умеете ли вы читать WSDL и XSD, описывать интеграцию так, чтобы разработчик не додумывал, и объяснять разницу с REST по существу, а не лозунгами.
Как отвечать
Дайте короткое определение и переходите к работе с контрактом. SOAP это обмен XML-конвертами поверх транспорта, практически всегда HTTP. Конверт состоит из Envelope с необязательным Header и обязательным Body, а ошибка возвращается отдельным элементом Fault с кодом и описанием.
WSDL для аналитика это источник правды: перечень операций, состав сообщений, типы через XSD, адрес сервиса. Оттуда берутся обязательность полей, кардинальность, допустимые значения и форматы.
В постановке описывайте:
- операцию и сценарий вызова, кто инициатор;
- маппинг полей источника и приёмника, включая справочники;
- поведение при отказе: перечень
Fault, что считается бизнес-отказом, а что технической ошибкой; - повторы и идемпотентность, тайм-ауты, порядок сообщений;
- объём и частоту вызовов, требования к журналированию.
Отличия от REST формулируйте так: жёсткий контракт с валидацией по схеме, собственные коды ошибок вместо статусов HTTP, набор стандартов расширения вроде подписи и шифрования сообщения.
Где спотыкаются
Сводят разницу к формату: «здесь XML, там JSON». Формат вторичен, REST тоже умеет отдавать XML. Различаются способ описания контракта, модель ошибок и наличие готовых стандартов на безопасность и надёжность доставки, и спрашивают обычно именно про это.
Второе: описывают только счастливый путь. В спецификации нет ни одного отказа, и разработчик сам решает, что делать при ошибке схемы или недоступности сервиса, а потом это всплывает на приёмке.
Третье: приносят из шаблона готовые проценты ускорения обработки заказов. На вопрос, что и чем измеряли до внедрения, ответить нечем, и вся история про интеграцию теряет вес.