HTTP-запрос в Tetiva состоит из метода, адреса, заголовков и тела. Главный источник истины — строка URL: query-параметры разбираются из неё во вкладку Params и собираются обратно, как только вы правите таблицу. Cookie живут отдельно от запроса — в хранилище воркспейса, которое переживает перезапуск приложения.
Метод и адрес#
Метод выбирается слева от адресной строки: GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD. Цвета методов — по конвенции Swagger UI; тот же цвет повторяется на бейдже запроса в сайдбаре.
Отправить запрос можно двумя способами: Enter прямо в строке URL или Cmd/Ctrl+Enter в любом месте вкладки. Сохранить — Cmd/Ctrl+S; несохранённые правки помечаются точкой у полосы вкладок.
В адресе подставляются переменные активного окружения: напишите {{base_url}}/v1/users, и перед отправкой {{base_url}} заменится на значение. Подробности — в разделе окружения и переменные.
Query-параметры#
Вкладка Params показывает параметры текущего адреса. Связь двусторонняя: допишете ?page=2 в строке — строка появится в таблице; отредактируете ячейку, добавите или удалите строку — адрес пересоберётся. Снятый флажок убирает параметр из адреса, не удаляя строку из таблицы.
Отдельного хранилища у параметров нет: в запросе сохраняется именно URL. Поэтому отключённая строка живёт, пока открыта вкладка, а после переоткрытия таблица снова строится из адреса.
Значения в таблице кодируются по правилам URL, так что переменную в query удобнее писать прямо в адресной строке: после правки строки в таблице {{token}} превратится в %7B%7Btoken%7D%7D и уже не подставится.
Заголовки#
Вкладка Headers — пары ключ-значение с флажком у каждой строки. Флажок сохраняется вместе с запросом: отключённый заголовок не уходит на сервер и не попадает в команду Copy as cURL. Так удобно держать рядом два варианта Authorization и переключаться между ними, ничего не удаляя.
Заголовок Content-Type Tetiva подставляет сама по типу тела — application/json для JSON, application/xml для XML, application/x-www-form-urlencoded для формы, application/octet-stream для бинарного файла. Заданный руками Content-Type не перезаписывается — кроме формы с файлами: она всегда уходит как multipart/form-data, и заголовок с вычисленным boundary Tetiva выставляет сама. См. тело запроса.
Авторизация настраивается на вкладке Auth и превращается в заголовок или query-параметр уже при отправке — см. авторизацию.
Cookie#
Tetiva держит собственное хранилище cookie на SQLite, отдельное для каждого воркспейса. Заголовки Set-Cookie из ответов сохраняются и прикладываются к следующим запросам того же домена — сценарий «логин отдаёт сессию, дальше работают остальные запросы» работает без ручного копирования.
Вкладка Cookies в ответе показывает две секции: Sent — что клиент приложил к этому запросу, Received — что пришло в Set-Cookie со всеми атрибутами. Ссылка «Manage cookies →» открывает менеджер: домены слева, таблица справа, можно добавить cookie руками, отредактировать, удалить одну, очистить домен или всё хранилище воркспейса.
Семантика — по RFC 6265, с одним осознанным упрощением:
- cookie без атрибута
Domain=считается host-only и матчится только на точный хост; сDomain=— на хост и поддомены. Добавленные вручную ведут себя как второй вариант; Set-CookieсMax-Age=0или датой в прошлом удаляет запись, поэтому серверный logout действительно чистит сессию;- cookie без явного
Path=получаютPath=/— RFC требует directory-default-path, здесь принято упрощение; - cookie без
ExpiresиMax-Age— сессионная: в менеджере у неё в колонке Expires написаноsession, как в DevTools браузера. Просроченные отсеиваются при чтении, сессионные хранятся до ручной очистки.
Что происходит при отправке#
Клиент ждёт ответ 30 секунд и проходит до 10 редиректов подряд, прикладывая cookie на каждом шаге. Ответ открывается во вкладках Body, Headers, Cookies и Tests — разбор ответа описан в просмотре ответа, а вкладка Tests наполняется скриптами.