Привет, коллеги! Меня зовут Василь Хамидуллин, и я тестировщик в компании fuse8.

REST API уже давно стал стандартом, но у него есть ограничения. Когда нагрузка растет, появляются потоковые сценарии или бизнес требует ускорения работы внутри сервисов, REST перестает быть ультимативным решением. gRPC решает то, с чем REST не справляется: обеспечивает высокую скорость передачи данных, поддерживает стриминг и дает строгую структуру взаимодействия. Его удобно использовать в микросервисах, мобильных и IoT-приложениях.

Для тестировщика это значит одно: умение работать с gRPC превращается из «будет плюсом» в обязательный навык. Если вы еще не работали с этим протоколом, то статья поможет понять его основы, отличие от REST, как устроены .proto-файлы, и самое главное – как тестировать gRPC-сервисы с помощью Postman.

Что такое gRPC и зачем он нужен?

gRPC — высокопроизводительный фреймворк от Google. Как тестировщику, вам не обязательно погружаться в тонкости реализации, но понимать, как устроен и как тестируется этот протокол точно будет не лишним.

Если упростить, REST можно сравнить с бумажными письмами, которые пересылаются в конвертах, а gRPC — с телефонным звонком. И то, и то – форматы общения между приложением и сервером, только в случае использования REST API данные передаются в JSON или XML форматах, которые вслед нашей аналогии можно отождествить с конвертами. Это окей и работает, но не всегда быстро и удобно.

gRPC предлагает оборачивание данных в бинарный (двоичный) протокол, который передаёт данные быстрее, меньше весит и строго структурирован. Тут используется Protocol Buffers (protobuf). Благодаря ему обе стороны, участвующие в обмене информацией, заранее знают, какие вопросы будут заданы и какие ответы ожидать. Для тестировщика это означает меньше двусмысленности и больше предсказуемости в проверках.

Когда мы впервые внедряли gRPC в проекте, неожиданно оказалось, что Postman по умолчанию не умел работать с этим протоколом. Пришлось искать обходные варианты — пробовали BloomRPC, потом grpcurl. В итоге нашли решение: загрузка .proto-файлов в новую бета-версию Postman. Это был полезный урок — не всегда инструмент готов «из коробки», и тестировщику важно держать под рукой несколько альтернатив.

Основные преимущества gRPC

Почему в продуктовой разработке все чаще можно встретить использование gRPC? Вот основные причины:

• Высокая производительность благодаря бинарному формату protobuf.

• Поддержка стриминга: данные можно передавать не только в формате «запрос-ответ», но и потоками.

• Кроссплатформенность: gRPC можно использовать для проектов на разных языках программирования. 

• Автогенерация кода: из .proto-файлов автоматически создается клиентский и серверный код.

Все это обеспечивает для нас меньше недопониманий с разработчиками, четкие правила для валидации и новые сценарии тестирования — например, для стриминга. 

Основные различия gRPC и REST:

Переход от тестирования REST к gRPC предполагает изменения в процессе на понятийном уровне. Вместо эндпоинтов и HTTP-методов — методы и сообщения, описанные в контракте. Для удобства проведем сравнение в таблице. 

Далее рассмотрим подробнее одно из преимуществ gRPC перед REST – наличие стриминга.

Типы gRPC вызовов

В отличие от REST, где есть привычные GET/POST/PUT/DELETE, gRPC работает с методами, которые задаются в .proto-файле.

Поддерживаются четыре вида вызовов:

1. Unary — один запрос, один ответ.

2. Server streaming — один запрос, поток ответов.

3. Client streaming — поток запросов, один ответ.

4. Bidirectional streaming — поток запросов, поток ответов.

Но чтобы понимать, какие методы доступны и какие данные можно передавать в этих вызовах, нужно разобраться, как устроен .proto-файл.

Как устроен .proto-файл

Это простой текстовый файл с расширением .proto. В нем мы как бы договариваемся: какие данные можно отправлять и получать, и какие есть методы у сервиса.

Можно представить, что это инструкция или договор между разработчиком сервиса и теми, кто его использует (например, тестировщиками).

Обычно .proto-файл составляет разработчик backend-сервиса, потому что он знает, какие методы должен поддерживать сервис, а также какие данные принимаются и возвращаются.
Тестировщик тоже может открыть .proto-файл, чтобы понять, как правильно составить запрос, предложить улучшение (например, добавить поле или поменять тип данных), а при желании написать свой .proto для обучения или экспериментов.

Прежде чем перейти к структуре .proto-файла, сделаем важное уточнение.

gRPC действительно передаёт данные в бинарном формате Protocol Buffers, а не в JSON — именно поэтому он эффективнее REST по скорости и объёму трафика. Однако при тестировании через инструменты вроде Postman, BloomRPC или grpcurl вы будете видеть запросы и ответы в удобочитаемом виде, напоминающем JSON. Это — визуализация бинарных данных для человека. Инструменты автоматически конвертируют бинарный поток в такой «псевдо-JSON», чтобы вам было проще работать с полями.

В наших примерах мы тоже будем использовать такой читаемый формат — не потому, что gRPC использует JSON, а чтобы вы могли быстро понять структуру сообщений.

Разберем простейший пример .proto-файла:

Что внутри

Указание синтаксиса

syntax = "proto3";

Syntax говорит, какую версию языка Protocol Buffers мы используем.
На момент написания статьи актуальна третья версия — proto3.

Определение сервиса

service HelloService {

  rpc SayHello (HelloRequest) returns (HelloResponse);

}

Service HelloService — объявление сервиса с именем HelloService. Можно думать о сервисе как о классе, внутри которого есть методы.
rpc SayHello (...) returns (...) — это описание удалённого вызова, где:

• SayHello — название метода.

• (HelloRequest) — что принимает метод (тип запроса).

• returns (HelloResponse) — что метод возвращает (тип ответа).

В нашем примере сервис имеет всего один метод SayHello, который принимает сообщение HelloRequest и отдает HelloResponse.

Описание сообщения запроса

message HelloRequest {

  string name = 1;

}

Message HelloRequest определяет тип данных для запроса. Внутри него:

• string name = 1;

  • string - тип данных (строка).

  • name - название поля.

  • = 1 - порядковый номер (нужен для сериализации).

Это значит: клиент должен передать строковое поле name.

Пример запроса:

Описание сообщения ответа

message HelloResponse {

  string message = 1;

}

Message HelloResponse определяет тип данных для ответа. Внутри:

• string message = 1;

  • строка, которая будет содержать результат.

В нашем случае сервер вернет строку-приветствие.

Пример ответа:

Все это вместе работает следующим образом: клиент вызывает метод SayHello, в запросе HelloRequest он отправляет поле name, сервер принимает это поле, формирует ответ, в ответе HelloResponse он возвращает строку с приветствием.

А теперь логично перейти к следующему вопросу: что еще сервис возвращает помимо полезных данных? Здесь поговорим о статус-кодах gRPC.

Статус-коды gRPC: что нужно знать тестировщику

В gRPC каждый ответ (даже успешный) сопровождается кодом статуса. Это не HTTP 200/404/500, а свой набор кодов, определенных в библиотеке gRPC. Всего в gRPC существует 17 предопределенных кодов состояния, от 0 до 16, но мы рассмотрим только самые основные и востребованные.

Основные статус-коды gRPC

Теперь, когда мы понимаем, как устроены методы (.proto) и какие статусы возвращаются, давайте посмотрим, как это все тестировать на практике с помощью Postman.

gRPC в Postman: тестирован��е на практике

Раньше в Postman можно было работать только с REST, теперь — и с gRPC.

Как выглядит работа:

1. Загружаем .proto-файл в Postman.

2. Выбираем сервис и метод.

3. Формируем запрос (данные берем из структуры запроса в .proto).

4. Смотрим на ответ и статус-код.

Например, для простейшего сервиса:

Запрос в Postman будет содержать поле name, а в ответ придет message — приветствие.

Давайте рассмотрим на примере.

• Создайте новый запрос → выберите тип запроса gRPC Request (не HTTP!).

• Укажите URL, откройте вкладку Service Definition, импортируйте .proto файл.

• После импорта .proto файла нам станут доступны все методы для выбора, с которыми умеет работать сервис.

• Выбираем нужный нам метод и в теле запроса появится JSON-подобная форма с полями, которые необходимо заполнить (все необходимые для заполнения поля определены в нашем .proto файле).

• Нажмите Invoke — и вы увидите ответ и статус-код

  

Итоги

• gRPC быстрее REST, поддерживает стриминг и строгие контракты.

• Для тестировщика ключевые навыки следующие: уметь читать .proto, проверять разные типы вызовов и работать с инструментами (Postman, grpcurl, BloomRPC).

• Не забывайте про статус-коды: они помогают понять, как сервис ведет себя в ошибочных сценариях.

• На практике могут встретиться подводные камни: не каждый инструмент поддерживает gRPC так же удобно, как REST.

Освоив gRPC, вы расширите свой арсенал: сможете проверять не только REST-сервисы, но и более современные микросервисные системы. А значит — станете более востребованным специалистом.