REST vs SOAP. Основи для ІТ аналітика
- Oleg Tovma
- 27 квіт.
- Читати 3 хв
Вебсервіси — це один із найпоширеніших способів інтеграції між системами. Два основні підходи до побудови вебсервісів — це REST та SOAP. Вони мають різні філософії, формати та сфери застосування. У цій статті розглянемо ключові відмінності, сильні й слабкі сторони кожного з підходів, а також приклади використання.
SOAP (Simple Object Access Protocol)
Загальна інформація
SOAP – це протокол, що визначає суворий формат обміну повідомленнями. В основі – XML-повідомлення, яке передається, зазвичай, через HTTP, але може працювати й через інші протоколи (SMTP, FTP тощо). Важливою частиною SOAP є WSDL (Web Services Description Language) – спеціальний файл, який описує, які саме функції доступні у сервісі, які дані потрібно передавати, та який результат очікувати.
Структура SOAP-повідомлення
Envelope – кореневий елемент, обов’язковий для всіх SOAP-повідомлень.
Header – необов’язковий блок для службової інформації (безпека, автентифікація, транзакції).
Body – основна частина, яка містить дані запиту або відповіді.
Приклад запиту та відповіді
Отримати користувача з ID = 123
Запит
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:user="http://example.com/user">
<soapenv:Header/>
<soapenv:Body>
<user:GetUserRequest>
<user:UserId>123</user:UserId>
</user:GetUserRequest>
</soapenv:Body>
</soapenv:Envelope>
Відповідь (SOAP XML)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:user="http://example.com/user">
<soapenv:Body>
<user:GetUserResponse>
<user:User>
<user:Id>123</user:Id>
<user:Name>Дмитро Петренко </user:Name>
<user:Email>d.petrenko@example.com</user:Email>
</user:User>
</user:GetUserResponse>
</soapenv:Body>
</soapenv:Envelope>
Переваги SOAP
Чіткий формат обміну повідомленнями – зменшує ризик неправильного трактування даних.
Підтримка WS-Security – шифрування повідомлень, автентифікація, цифрові підписи.
Підтримка транзакцій – можливість групувати кілька операцій в одну логічну транзакцію (ACID-властивості - детальніше про атомарність операцій у веб-сервісах можна прочитати ось тут).
Ідеальний для корпоративних систем – банківські системи, CRM, ERP.
Недоліки SOAP
Складність у впровадженні та налаштуванні.
"Важкі" повідомлення (через XML і надлишковість тегів).
Менша гнучкість – прив’язка до суворого контракту в WSDL.
REST (Representational State Transfer)
Загальна інформація
REST – це архітектурний стиль, який базується на принципах HTTP-протоколу. У REST-інтерфейсах ресурси (користувачі, товари, замовлення тощо) ідентифікуються URL-адресами, а дії над ними виконуються за допомогою стандартних методів HTTP: GET, POST, PUT, DELETE.
Методи
Метод | Призначення | Тип дії |
GET | Отримання ресурсу | Читання (Read) |
POST | Створення нового ресурсу | Створення (Create) |
PUT | Повне оновлення наявного ресурсу | Оновлення (Update) |
DELETE | Видалення ресурсу | Видалення (Delete) |
Приклади REST-запитів
GET – Отримання ресурсу
Використовується для отримання даних без зміни стану сервера.
Приклад:
Пояснення:Отримуємо інформацію про користувача з ID = 123.
Приклад відповіді (JSON):
{ "id": 123, "name": "Дмитро Петренко", "email": "d.petrenko@example.com" }
POST – Створення нового ресурсу
Використовується для створення нового запису на сервері.
Приклад:
POST https://api.example.com/users Content-Type: application/json { "name": "Олена Іваненко", "email": "o.ivanenko@example.com" }
Пояснення:Створюємо нового користувача із вказаним ім'ям і електронною адресою.
Приклад відповіді (201 Created):
{ "id": 124, "name": "Олена Іваненко", "email": "o.ivanenko@example.com" }
PUT – Повне оновлення ресурсу
Використовується для повної заміни наявного ресурсу новими даними.
Приклад:
PUT https://api.example.com/users/123 Content-Type: application/json { "name": "Дмитро П. Петренко", "email": "d.petrenko@example.com" }
Пояснення:Оновлюємо інформацію про користувача з ID = 123, переписуючи всі його поля.
Приклад відповіді:
{ "id": 123, "name": "Дмитро П. Петренко", "email": "d.petrenko@example.com" }
DELETE – Видалення ресурсу
Використовується для видалення ресурсу на сервері.
Приклад:
Пояснення:Видаляємо користувача з ID = 123 із бази даних.
Приклад відповіді (204 No Content):
Успішне видалення. Тіло відповіді зазвичай порожнє.
Переваги REST
Простота – мінімальні вимоги до форматування запитів і відповідей.
Широка підтримка браузерами та мобільними додатками.
Висока продуктивність – легкі повідомлення (особливо при використанні JSON).
Гнучкість – легко розширювати API без порушення роботи клієнтів..
Недоліки REST
Відсутність суворого стандарту опису сервісу (хоча сучасні OpenAPI/Swagger частково вирішують це питання).
Обмежені можливості для складних транзакцій, які охоплюють кілька ресурсів.
Безпека реалізується вручну через HTTPS, OAuth, токени доступу тощо.
Різниця між SOAP та REST
Якщо коротко підсумувати різницю, то можна отримати наступну таблицю:
Критерій | REST | SOAP |
Формат | JSON (або XML) | XML |
Стандартизація | Низька | Висока (WSDL, WS-Security тощо) |
Протоколи | HTTP | HTTP, SMTP, FTP |
Простота | Висока | Низька (більше коду, налаштувань) |
Підтримка транзакцій | Обмежена | Повна підтримка |
Безпека | На рівні HTTPS | WS-Security |
Придатність | Веб і мобільні API | Корпоративні сервіси, банкінг |
Чому це важливо для системного аналітика?
Знання різниці між REST і SOAP важливе для бізнес-аналітика, оскільки воно:
Допомагає краще розуміти можливості й обмеження інтеграцій між системами.
Дозволяє точніше формулювати вимоги до API в ТЗ або User Stories.
Сприяє кращій співпраці з розробниками та архітекторами при виборі технічного рішення.
Що враховувати при виборі між REST та SOAP
Ситуація | Рекомендовано |
Потрібна проста інтеграція для веб/мобільного додатку | REST |
Потрібна висока надійність і складні транзакції | SOAP |
Фокус на швидкості розробки й масштабованості API | REST |
Жорсткі вимоги до безпеки та відповідності стандартам | SOAP |
Підсумок
REST більше підходить для сучасних гнучких рішень, тоді як SOAP залишається актуальним у корпоративних, фінансових і державних системах.
Якщо ви маєте бажання поглибити свої технічні знання, зверніть увагу на тренінги Technical skillsfor Business Analyst та Advanced Technical skills for Business Analyst
Comments