Не все API устроены одинаково. Новички часто сводят всё к одной схеме: "есть endpoint, я отправил запрос, получил ответ". На практике моделей взаимодействия несколько, и для QA это важно. От выбранного подхода зависят формат данных, тип контракта, поведение ошибок, возможности real-time, требования к версии API и даже набор инструментов для тестирования.
Эта тема нужна не для того, чтобы выучить пять модных слов. Она нужна, чтобы быстро понимать, с чем ты вообще работаешь и где у такого подхода типичные риски.
REST
REST - это архитектурный стиль, который чаще всего используется поверх HTTP. Обычно в REST API есть ресурсы, URL, стандартные методы вроде GET, POST, PUT, PATCH, DELETE и ответы со статус-кодами.
Для QA это самый привычный формат в web и mobile продуктах. Его удобно читать в DevTools, Postman и логах gateway. Если API построен аккуратно, по URL, методу и статусу уже можно быстро понять, что происходит.
Но важно помнить: REST - это не "любой JSON по HTTP". Если в системе всё называется REST, но при этом нет нормальной модели ресурсов, методы используются хаотично, ошибки возвращаются непредсказуемо, а бизнес-действия упакованы в случайные endpoint'ы, QA придётся тестировать не стиль, а набор договорённостей конкретной команды.
SOAP
SOAP - это более формальный подход к обмену сообщениями, исторически очень распространённый в enterprise и legacy-системах. Здесь обычно используются XML-сообщения, строгие схемы, контракты и стандартизированная модель ошибок.
Для QA SOAP важен потому, что он до сих пор встречается в банках, страховании, телекоме, госинтеграциях и других тяжёлых корпоративных системах. Там часто ценятся не "простота для frontend", а предсказуемость, формальный контракт и совместимость между большими интеграциями.
Если REST часто читается быстрее глазами, то SOAP обычно требует больше внимания к структуре XML, schema validation, namespace, fault-сообщениям и совместимости форматов. Он кажется тяжёлым, но у него сильная сторона - строгость контракта.
GraphQL
GraphQL - это query language и runtime для API, где клиент сам указывает, какие поля он хочет получить. Это уменьшает проблему избыточных или недостаточных данных в ответе и даёт frontend более гибкий способ получать нужную структуру.
Для QA здесь меняется сама логика тестирования. В REST ты часто проверяешь отдельные endpoint'ы. В GraphQL ты чаще думаешь про schema, поля, типы, резолверы, доступ к данным и комбинации запросов.
- →ошибки прав доступа могут проявляться на уровне отдельных полей, а не только endpoint'а
- →один запрос может стать слишком тяжёлым по глубине и стоимости
- →часть проблем скрывается не в транспортном слое, а в schema и resolver logic
- →ответ может прийти с частичными данными и блоком errors, и это нужно уметь правильно интерпретировать
Для QA GraphQL удобен тем, что контракт обычно хорошо описан схемой. Но тестировать его "как обычный REST" уже нельзя.
gRPC
gRPC - это современный RPC-фреймворк, который часто используется для service-to-service взаимодействия. Обычно он работает поверх HTTP/2 и часто использует Protocol Buffers как компактный бинарный формат.
Для QA важно понимать простую вещь: gRPC чаще живёт не на поверхности web-продукта, а внутри распределённой системы. Это значит, что его часто встречают в микросервисах, внутренних интеграциях, high-load сервисах и streaming-сценариях.
- →более строгий контракт
- →высокую производительность
- →генерацию клиентских и серверных stub'ов
- →удобный streaming
Но для ручного QA он менее "прозрачный", потому что ты не всегда можешь так же легко глазами читать сообщения, как JSON в REST. Здесь особенно важны схема, protobuf definitions, совместимость версий и корректная работа streaming-вызовов.
WebSocket
WebSocket нужен там, где недостаточно обычной модели request-response. Он открывает постоянное двустороннее соединение между клиентом и сервером, чтобы обе стороны могли отправлять сообщения без постоянного повторного опроса.
- →чаты
- →trading и live-данные
- →real-time dashboard
- →игры
- →совместное редактирование
- →уведомления с мгновенной доставкой
Для QA это уже другой тип рисков. Здесь мало проверить один запрос и один ответ. Нужно смотреть на жизненный цикл соединения: подключение, переподключение, порядок сообщений, потерю событий, дубли, гонки, heartbeat, авторизацию на канале и поведение при плохой сети.
То есть WebSocket - это не "ещё один endpoint". Это уже модель постоянного состояния и обмена сообщениями во времени.
Что важно QA
Главное - не пытаться тестировать все эти подходы одинаково.
Если перед тобой REST, ты смотришь на ресурсы, методы, статус-коды, структуру ответа и идемпотентность операций.
Если перед тобой SOAP, тебе важнее формальный контракт, XML-схема, обязательные поля, fault-модель и совместимость интеграции.
Если это GraphQL, нужно проверять schema, права доступа к полям, частичные ошибки, комбинации запросов и тяжёлые query.
Если это gRPC, на первый план выходят protobuf-контракт, backward compatibility, streaming и поведение сервисов под нагрузкой.
Если это WebSocket, ты тестируешь соединение, последовательность событий, переподключение, устойчивость канала и real-time поведение.
Сильный QA не просто знает названия технологий. Он понимает, какую модель взаимодействия выбрала система и где в этой модели самые вероятные дефекты.
Что должен вынести QA из этой темы
- →REST, SOAP, GraphQL, gRPC и WebSocket решают разные задачи.
- →REST и SOAP чаще ассоциируются с запросом и ответом, но отличаются степенью формальности и стилем контракта.
- →GraphQL переносит часть сложности в schema, поля и resolver logic.
- →gRPC часто важен для внутренних сервисов и требует внимания к контракту и совместимости.
- →WebSocket нужен для real-time и требует тестирования поведения соединения во времени.
- →Один и тот же набор проверок нельзя механически переносить между этими подходами.
Что ещё почитать
- →Внутри базы: Методы, статус-коды, заголовки
- →Внутри базы: Contract testing
- →Внешний материал: GraphQL Learn