Чем REST отличается от SOAP? Какие принципы REST вы знаете?
Короткий ответ
- REST — архитектурный стиль поверх HTTP, SOAP — протокол
- REST обычно использует JSON, SOAP — строго XML
- SOAP имеет жёсткий контракт WSDL и конверт сообщения
- REST: ресурсы, методы GET POST PUT DELETE, коды ответов
- REST stateless: сервер не хранит состояние клиента
- SOAP жив в банках, госсистемах и легаси-интеграциях
- Выбор диктуется контрагентом и требованиями к контракту
REST — лёгкий архитектурный стиль на ресурсах и методах HTTP с JSON, SOAP — строгий XML-протокол с контрактом WSDL, до сих пор распространённый в банковском и государственном секторе.
Как сказать вслух
пример ответаREST — это архитектурный стиль поверх HTTP: мы работаем с ресурсами через стандартные методы — GET для чтения, POST для создания, PUT и PATCH для изменения, DELETE для удаления, а статус операции передаётся кодами ответа. Данные обычно в JSON, сервер не хранит состояние клиента. SOAP — это строгий протокол: XML-конверт, формальный контракт в WSDL, свои стандарты безопасности. SOAP тяжелее, но до сих пор живёт в банках и госсистемах, поэтому аналитику приходится работать с обоими.
Подробный ответ
Основной ответ
REST (Representational State Transfer) — архитектурный стиль: система представляется набором ресурсов с URI, операции выполняются стандартными методами HTTP (GET, POST, PUT, PATCH, DELETE), результат сообщается кодами состояния (200, 201, 400, 404, 500), взаимодействие stateless — каждый запрос самодостаточен. Формат тела чаще JSON, контракт описывают OpenAPI. SOAP — протокол обмена XML-сообщениями с обязательной структурой Envelope/Header/Body, формальным контрактом WSDL, передачей поверх HTTP или других транспортов и стеком стандартов WS-* (WS-Security, транзакции). SOAP строже и тяжелее, но даёт жёсткую типизацию и распространён в банковской сфере, страховании и госинтеграциях (СМЭВ). REST проще, легче для веба и мобильных клиентов. Аналитик выбирает не «что моднее», а что поддерживает контрагент и какие требования к контракту и безопасности.
Ключевые моменты
- Семантика методов. GET — чтение без побочных эффектов, POST — создание, PUT/PATCH — полная и частичная замена, DELETE — удаление; GET, PUT и DELETE идемпотентны.
- Коды ответов. 2xx — успех, 4xx — ошибка клиента (валидация, авторизация), 5xx — ошибка сервера; аналитик описывает их в спецификации.
- Контракты. Для REST — OpenAPI/Swagger, для SOAP — WSDL с XSD-схемами; оба позволяют генерировать код и валидировать сообщения.
- Stateless. Сервер не хранит контекст между запросами — это упрощает масштабирование, а состояние передаётся в токене или параметрах.
Практический контекст
Системный аналитик описывает REST-методы ежедневно: ресурсы, параметры, тела, коды ошибок. SOAP всплывает при интеграции с банками, страховыми и госсервисами, где нужно читать WSDL. На собеседовании любят уточнить разницу PUT и PATCH, спросить, какой код вернуть при ошибке валидации, или почему GET не должен менять данные — так проверяют практику, а не заученное определение.
Частые ошибки
- Называют REST протоколом и не могут назвать ни одного его принципа
- Не знают разницу между PUT и PATCH или смысл кодов 4xx и 5xx
- Пренебрежительно списывают SOAP, хотя интеграции с банками и госсистемами на нём