gRPC-запрос в Tetiva начинается со схемы: без дескрипторов клиент не знает, как закодировать сообщение. Схему можно получить от самого сервера через server reflection или собрать локально из .proto-файлов. Дальше всё привычно — выбираете метод, правите JSON-тело, добавляете metadata и жмёте Invoke. Выполняются unary-вызовы; потоковые методы видны в списке, но вызвать их из приложения нельзя.
Адрес и схема через reflection#
Адрес пишется без схемы URL — localhost:50051 или api.example.com:443. Кнопка Load services открывает соединение и запрашивает у сервера список сервисов; служебные grpc.reflection.* в список не попадают. Соседняя кнопка с круговой стрелкой перечитывает схему, когда сервер пересобрали.
В адресе работают переменные окружения, так что один запрос переключается между стендами сменой активного окружения — см. окружения и переменные.
Соединение устанавливается без TLS: gRPC-сервер должен быть доступен по plaintext. Для локальной разработки и внутренних стендов этого хватает, для gRPC за TLS-терминатором — пока нет.
Импорт .proto#
Если reflection на сервере выключен, кнопка Import .proto предлагает два варианта. Import File берёт один файл; каталог файла и до пяти родительских каталогов добавляются как import paths, поэтому импорты вида common/v1/types.proto обычно резолвятся сами. Import Directory рекурсивно собирает все .proto внутри выбранного каталога — это надёжный вариант для схемы, разложенной по пакетам.
Выбранный источник показывается чипом с именем файла или каталога: круговая стрелка перечитывает его с диска, крестик очищает путь и возвращает запрос к reflection. Путь хранится вместе с запросом, поэтому после переоткрытия вкладки источник схемы не нужно выбирать заново.
Выбор метода и тело#
Выпадающий список объединяет сервисы и методы: есть поиск по подстроке и навигация стрелками. Рядом с каждым методом — бейдж формы вызова: UNARY, SERVER, CLIENT или BIDI. Invoke отрабатывает только для UNARY, остальные вернут ошибку о том, что метод потоковый.
Кнопка Generate Example собирает JSON-тело из входного типа: строки пустые, числа нулевые, bool — false, enum — первое значение, для repeated создаётся массив из одного элемента, для map — одна пара. Рекурсивные сообщения не разворачиваются бесконечно. Это заготовка, а не валидный доменный запрос: перед вызовом замените заглушки настоящими значениями, иначе сервер, скорее всего, ответит INVALID_ARGUMENT.
Отправить вызов — Cmd/Ctrl+Enter или кнопка Invoke, сохранить запрос — Cmd/Ctrl+S.
Metadata вместо вкладки Auth#
У gRPC-запроса нет вкладки Auth: всё, что нужно серверу, передаётся через metadata. Вкладка Metadata — те же пары ключ-значение, что и заголовки в HTTP; в значениях подставляются переменные окружения, так что токен обычно выглядит как authorization: Bearer {{access_token}}.
Общий для всей коллекции токен удобно ставить pre-скриптом на коллекции: скрипты наследуются вложенными запросами, а pm.request.metadata.set('authorization', ...) пишет ключ в metadata текущего вызова. Как устроено наследование — в разделах скрипты и авторизация.
Вкладка Schema и разбор ответа#
Вкладка Schema показывает proto-определения выбранного метода: входное сообщение, выходное сообщение и сигнатуру rpc с пометками stream. Внизу указан источник — reflection, файл или каталог, — а кнопка Open in Window выносит схему в отдельное окно, чтобы держать её рядом с телом запроса.
Ответ разложен по вкладкам Body, Metadata и Tests. В Metadata попадают заголовки и трейлеры вызова, слитые в один список. Ненулевой gRPC-статус — это не сбой запроса: приложение покажет код и его имя (NOT_FOUND, PERMISSION_DENIED) вместе с текстом сообщения от сервера. На соединение и на сам вызов отводится по 30 секунд.