Blog A.Wolf
This step-by-step guide is describing how to set up a Postman collection to query a JSON RPC API. We’ll do a query to the Solana dev. network RPC API but you can query everything that is JSON RPC complaint. To get every detail about JSON RPC you can find the docs here but we’ll cover the basics in this post.
At the moment, there is no native implementation of JSON RPC requests in postman but there is a feature request on Github.
So we have to do a manual setup to easily generate requests by simply naming the request like the method and changing the parameters (if needed) in a pre-request script.
Before we start with the Postman setup, we’re looking at a JSON-RPC query and what is needed.
TL/DR You can also find the result of the guide in the Postman web app
RPC query
First, we need to have a look in the Solana JSON RPC docs to know which method we want to query.
In the example, we query the getBlockHeight method. This will return us the total number of blocks in the Solana blockchain.
What are the details for the query?
- POST method
- URL https://api.devnet.solana.com
- Headers «Content-Type: application/json»
- body
For the URL we picked the dev. net because we’re just doing the first tests and that’s OK to do on the dev net. For the available endpoints, please have a look here.
"jsonrpc": "2.0" is telling that we’re using the RPC api version 2.0 .
The id is a unique client-generated identifying integer. We selected the number one but in an app, you would generate a unique integer. But for now, it’s OK to hardcode it.
method is the method we’re interested in. params is an empty array here as we don’t need anything for this query.
Content-Type is application/json because we’re transferring and receiving JSON data (automatically added by Postman because we’re having JSON data in the body)
The expected result will look similar to this:
Postman
We’re using the desktop version of Postman. If you don’t have it installed yet, go to Postman, download and install it for your operating system.
The description here will also work for the web version. So if you prefer the web version you can find it here.
- Create a new collection in your workspace — click new and select Collection
2. Name your collection «Solana devnet» in the already selected field alt=»Postman new collection» />3. Setup of your collection
- Variables tab: Add API_URL https://api.devnet.solana.com for initial & current value.

- Pre-request Script tab: Add the following lines (we’ll use the env. variables in the body)

- Click Save to save the collection
- Next, create the first request by clicking Add a request in your collection and name it getBlockHeight . Important, name it exactly like the RPC method, so we can use this directly for the request.
- Select POST as the method and enter the URL <
> — double curly braces are used to access the variable API_URL - Now, select Body , click raw , pick JSON and insert the following data
- Click Save to save the request
- Finally, click Send to test the query. If everything is working as expected, you should see a response like in the below screenshot:

Why are we doing that configuration?
The variable API_URL will be used in every request so with a variable it’s easier to change it later e.g. we’d like to do the same request for a local test net it only requires this little change to use it in any request.
The pre-request script runs before every request and it sets the environment variable METHOD to the name of the request (here getBlockHeight ) and the params to an empty array.
How to create another request?
Simply right-click & duplicate or Ctlr+D to duplicate the previous request. And rename the request to the new name e.g. getHealth and that’s it.
How about adding a parameter?
Create a duplicate of a request. Rename it to getBlocksWithLimit . In the Pre-request Script tab of the request add:
This will change the previously set PARAMS to [0, 3] . So the result will be
Optional step
We can change the pre-request step of the collection so that we can add more information to the request name e.g. getBlocksWithLimit_0withLimit3
Just change the script in the collection:
Writing tests in Postman
You can change to the Tests tab and write test cases for each request in your collection.
The test will automatically run if you send the request and the result will be displayed in the Test Results tab.
For a detailed description of possible tests, please have a look at the docs.
For the getBlockHeight request a test could be:
The result of the test will be displayed like in the following screenshot: 
Troubleshooting
If you’re not getting the correct response or having trouble during writing your tests, click on Console in the lower-left corner and check the last request. 

Points to check:
- Request body:
- Is it available?
- What data is there? E.g. variable not correctly used
- Anything missing?
- Content-type correctly set
Conclusion
I’m happy with the setup as it’s easy to create new requests and learn more about each endpoint without thinking about how to write the query.
With the optional step, it’s possible to add a description to more complicated routes. If you have an idea to improve the setup, please let me know in the comments below or write me on Twitter.
It would be also possible to pass parameters with the request name but that’s probably not worth it as the parameters could be more complicated than just two array values. So this would get complicated and hard to read.
API тестирование с помощью Postmen
Аббревиатура API расшифровывается как «Application Programming Interface» (интерфейс программирования приложений или программный интерфейс приложения). Технология API это описание способов (набор классов, процедур, функций, структур и констант), которыми одна компьютерная программа может взаимодействовать с другой программой.
Углубляться в теорию мы не будем. Нас интересует только понятие API Вызовов в WEB среде, с которыми мы будем работать.
Простыми словами, API Вызовы это запросы, которые имеют вид ссылки (иногда называются Роуты), и передаются на определенный хост, для получения или отправки информации. API вызовы могут содержать дополнительные параметры, для уточнения полученной выборки или отправляемой информации.Также нужно знать что стандартными методами для HTTP протокола (по которому мы отправляем запросы) являются — GET (запросить), PUT(заменить или обновить), DELETE(удалить), POST(отправить).
НО, эти методы таким способом только для HTTP протокола. И соотвественно для API, которое реализованно с помощью подхода который базируется на HTTP протоколе.
Тоесть возможна реализация API на базе только метода POST, который будет и отправлять и получать и удалять информацию.Типами данных которые мы передаем в теле запроса являются (Подробнее читать тут):
- Text — application/x-www-form-urlencoded
- text/plain — application/json
- text/xml — application/javascript
- text/html — application/xml
- multipart/form-data
- application/x-www-form-urlencoded
- application/json
- application/javascript
- application/xml
Основные подходы к реализации WEB API
Важно понимать что технология API имеет множество подходов к реализации, и каждый из них имеет свои стандарты.
Рассмотрим три основных подхода:- Простой протокол доступа к объектам SOAP (Simple Object Access Protocol);
- Передача состояния представления REST (Representational State Transfer) ;
- Удаленный вызов процедур JSON-RPC (Remote Procedure Call).
Некоторые разработчики могут не согласиться с тем, что SOAP «прост», потому что, для выполнения вызовов необходимо использовать формат XML. Данный формат не совсем интуитивно понятен, что не только затрудняет реализацию вызовов, но и затрудняет отладку.
С другой стороны, SOAP использует как транспортные, стандартные протоколы (например HTTP).Базируется на транспортном протоколе HTTP для обмена информацией между различными приложениями или службами. REST более гибок, чем SOAP в том смысле, что поддерживает различные форматы данных, а не требует XML,(к примеру JSON).
REST API также может предложить лучшую производительность, чем SOAP, поскольку он может кэшировать данные.JSON-RPC
По сравнению с REST и SOAP JSON-RPC относительно узок по возможностям. Он поддерживает исключительно небольшой набор команд и не обеспечивает такой гибкости, как REST, он поддерживает только один формат передачи данных — JSON .
Зато данный подход не базируется на стандартных протоколах, а только использует их как транспортные. Можно сказать что JSON-RPC независим от протоколов.SOAP REST JSON-RPC Поддерживает форматы XML JSON, XML. e.t.c JSON Данные запроса могут быть: В URI запроса
В GET параметрах
В HTTP заголовкахВ URI запроса
В GET параметрах
В HTTP заголовкахВ теле запроса Данные ответа могут быть: В HTTP коде ответа
В HTTP заголовках
В теле ответа (формат не стандартизирован)В HTTP коде ответа
В HTTP заголовках
В теле ответа (формат не стандартизирован)В теле ответа (формат стандартизирован) Примеры API (Использование в WEB)
Для примера мы будем использовать сервис Новой Почты и SendPuls.
API NovaPoshta- ссылка
API SendPuls — ссылкаДля начала рассмотрим пример с SendPuls.
Вот Наша ссылка на сервер API запросов: https://api.sendpulse.com/
Возьмем POST запрос на авторизацию — oauth/access_token
Формат передачи данных: application/x-www-form-urlencodedParameter Value grant_type* client_credentials client_id* YOUR ID client_secret* YOUR SECRET Этот POST запрос передается в формате Form-Data и будет иметь структуру:
Теперь рассмотрим пример с Новой Почты
Вот Наша ссылка на сервер API запросов: https://api.novaposhta.ua/v2.0/json/
Возьмем простой POST запрос на получение списка городов — Address/searchSettlements
Тип передачи данных — application/jsonParameter Data type Value apiKey* string[36] YOUR API KEY modelName* string Address calledMethod* string searchSettlements CityName* string[36] Львів Limit* int[36] 5 Таким образом наш POST запрос в формате JSON, будет иметь структуру:
Что такое Postman и для чего он нужен
Как Вы убедились ранее, для отправки API вызовов нужны знания синтаксиса языка программирования, на котором вы собираетесь отправляется запрос, и кроме этого нужна среда, в которой вы сможете написать и отправить данный запрос.
Тут нам на помощь приходит приложение Postman.Postman это десктоп приложение, (существует и в виде расширения для Google Chrome), которое содержит набор инструментов для тестирования API. Это приложение позволяет выполнять API вызовы с помощью визуального интерфейса, без использования кода, а также выполнять авто проверку ответа.
Для чего и кому он нужен?
Postman нужен тестировщиком для прогона позитивных тест кейсов связанных с API, в ходе дымового, модульного тестирования или регрессионного тестирования.
Postman также подходит и для разработчиков для того чтобы составить API модель приложения и проверять реализованные роуты.Какие возможности приложения:
- Создание Коллекций и шаринг коллекций;
- Построение иерархий Папок внутри одной коллекции;
- Создание Запросов, и настройка их параметров;
- Написание Скриптов, которые могут выполнятся перед запросом и после него;
- Настройка Окружения;
- Использование переменных;
- Запуск коллекции;
- Работа в консоли.
Интерфейс Postman
Итак рассмотри интерфейс приложения и основные его элементы.

- Меню Коллекций;
- Вложенные в коллекцию папки;
- Запросы;
- Конструктор запросов:
- URL и метод;
- Параметры запроса;
- Параметры ответа;
Далее Вы можете использовать мою презентацию для рассмотрения всего функционала более детально. Функционал создания папок и Коллекций, а так же создание запросов был показан в ходе демонстрации, и не присутсвует в презентации, эту информацию Вы сможете взять в учебном центре Postman.
Выступление с данной презентацией происходило в компании GalobalLogic 03.07.2019. Размещено с разрешения сотрудников компании.
Как перестать страдать и начать пользоваться Postman
Если на вашем счету уже есть не одно разработанное приложение, использующее REST API или сами создавали REST API, то наверняка слышали о Postman. В этой заметке хочу показать на нескольких примерах основную функциональность этого приложения для остальных — тех, кто еще только начинает заниматься подобными проектами.
Введение
Создавали ли вы REST API? Или приложения, которые используют некий сторонний REST API? Если вы ответили утвердительно хотя бы на один из этих вопросов, то вы поймёте мою боль.
Ранее (очень ранее) для подобных задач я создавал отдельный файл, в котором сохранял JavaScript-сниппеты, которые выполняли REST-запросы к тестируемым API. Моим обычным пайплайном при обращении к среднестатистическому API был следующий:
- Копируем нужный запрос из файла
- Выполняем запрос на получение token-а
- Копируем следующий запрос из файла
- Копируем token в новый запрос
- Выполняем запрос на получение данных
Пункты 3-5 могут продолжаться еще несколько раз. Если это одноразовая задача, то проблем нет — выполнил и забыл. Однако, если вы используете этот API в своём приложении или сами являетесь разработчиком API, то выполнять эту пачку запросов требуется многократно и делать это становится неприятно. В этот момент появляется ОН — Postman.
Создатели Postman так описывают свой проект:
Postman is the swiss army knife of API tools, allowing you to design, build, test, document and monitor your services, all in one place.*
Если вкратце и по-русски, то Postman — это комбайн, который позволяет создавать и выполнять запросы, документировать и мониторить ваши сервисы в одном месте.
Установка
Postman доступен как Chrome App, который можно установить из магазина приложений Chrome, и standalone приложения для MacOS. Версии для Linux пока нет, но авторы обещают в скором времени это исправить. Postman доступен как standalone-приложение для Windows, MacOS и Linux.
На момент написания данной статьи так же существовала версия для Google Chrome о которой пойдёт речь в этой статье.
Выполнение запросов
Базовая функциональность довольная проста: для выполнения элементарных запросов достаточно:
- выбрать тип запроса
- вбить запрос в соответствующее поле …
- … или заполнить параметры через форму
- нажать кнопку «Send»

Если все сделано правильно, то в нижней части окна отобразится результат выполненного запроса. В моём случае — запрос к знакомому по предыдущим постам API StackOverflow:
«Этот пример примитивен и выполнить это проще в %Developer-Tools-Fav-Browser%!» — скажет любой, и я с этим соглашусь. Однако есть как минимум одно «но»: этот запрос можно сохранить и выполнять в будущем только изменяя соответствующие параметры. Более того, запросы можно группировать в коллекции.
Коллекции запросов
Сайт thetvdb.com предлагает возможность получать информацию по различным сериалам посредством их REST API. Однако, каждый запрос должен содержать в заголовках полученный при аутентификации токен. Таким образом для того, чтобы получить информацию по сериалу «Walking Dead» необходимо выполнить два запроса: получение токена и поиск.
Создадим новый POST-запрос на адрес
для получения токена:

Заполним форму с заголовками как указано на изображении выше и добавим в тело запроса нужный JSON и изменим тип на raw (apikey, username и userkey можно получить в личном кабинете после регистрации на вышесказанном сайте):

На данный момент этого достаточно и можно опять жать на «Send». В ответ на этот запрос нам придёт JSON вида
Первую часть сделали. Теперь, для того чтобы найти сериал «Walking Dead», нам необходимо выполнить GET-запрос на следующий адрес:
Создаем новый запрос, заполняем адрес и добавляем новый заголовок Authorization в соответствующем разделе (1):

В ответе можно увидеть JSON с полученными сериалами: «The Walking Dead» и «Fear the Walking Dead» и их краткими описаниями (2).
Чтобы в дальнейшем можно было просто найти эти запросы — сохраним их через меню «Save As…» и добавим в коллекцию «thetvdb»:

Теперь в панели слева у нас будет новая коллекция «thetvdb».
Выполнение коллекций запросов и тестов
Предыдущий раздел показал, что можно упростить выполнение рутинных действий сохранив запросы и выполнять их с заготовленными параметрами. Однако, после 2-3 однообразных циклов:
- Получи токен
- Скопируй токен в заголовок запроса
- Выполни запрос к API
Это начинает надоедать.
И тут на помощь приходит сумасшедшая возможность Postman — выполнение коллекций запросов с добавлением некоторых небольших (а можно и больших) скриптов.
Улучшим предыдущие запросы таким образом, чтобы при выполнении запроса на получение токена ничего в последующие вопросы копировать не потребовалось. Для этого есть связка из вкладки Tests, окружений (Environment) и переменных этого окружения. Про переменные есть отдельная статья.
Во-первых, необходимо создать новое окружение в соответствующем разделе:



Никакие ключи добавлять не будем — сейчас нам это не надо.
Созданное окружение необходимо выбрать в соответствующем выпадающем списке:

Во-вторых, откроем запрос на получение токена и перейдём на вкладку Tests (см. скриншот выше) и добавим следующий код:
Этот скрипт только лишь преобразует строку в JSON и сохраняет в переменную текущего окружения «token» свойство token полученного объекта.
На самом деле эта вкладка предназначена немного для других целей (для написания тестов, внезапно), но сейчас об этом говорить не будем. Возможно, в следующий раз доберусь и до этого.
В-третьих, изменим запрос на получение списка сериалов «Walking Dead» таким образом, чтобы токен получался из переменных окружения. Для этого достаточно в заголовке Authorization строку токена заменить на сниппет <
>: 
Теперь после выполнения запроса для получения токена можно сразу же выполнять запрос на поиск сериала без лишних манипуляций с копированием полученного токена.
Можно проверить, что всё работает корректно выполнив всю коллекцию запросов через соответствующее меню коллекции:

В открывшемся меню выбираем нужную коллекцию и жмём большую синюю кнопку «Start Test», которая выполнит все запросы выбранной коллекции в той последовательности, в которой они сохранены:

Как можно видеть на скриншоте все запросы завершились удачно. К сожалению, содержимое ответов этих запросов посмотреть здесь нельзя. Оно и правильно — возможность выполнения коллекции запросов предполагается для тестирования API в первую очередь.
Генерация сниппетов
И, напоследок, хотелось бы упомянуть об одной очень крутой фиче Postman — генерация кода из запроса. Список поддерживаемых языков программирования (и не только) довольно широк: от OCaml и cURL до Swift и Go.
Пример кода, сгенерированного Postman для поиска по StackOverflow на Golang:
И в добавок на Python с использованием библиотеки Requests:
Как мне кажется, код выглядит приемлемым более чем и вполне годится как отправная точка для дальнейшего шлифования.
Выводы
Вывод только один — если вы еще не используете в повседневной работе Postman, то, вероятно, скоро начнёте. Если нет, то, видимо, оно вам не надо и вы хотите еще больше страданий.
UPD: Неожиданно для себя — записал вебинар для Geekbrains по этой теме:
UPD2: Если вам понравилась статья, можете присоединиться к моему telegram-каналу https://t.me/makesomecode. В канал попадают новые статьи и небольшие заметки по Python, C#, Golang
*) Postman — это швейцарский нож для работы с API, который позволяет создавать, тестировать, документировать и мониторить ваши сервисы из одного места.
Жизнь — это движение! А тестирование — это жизнь 🙂
Он есть в методе CreateUser — и для задач, и для компаний.
В json формате он выглядит так:
<
«email»: «test_cu_32@mail.com»,
«name»: «Рест 32»,
«tasks»: [39],
«companies»: [15, 20]
>Простой массив в json В form-data мы указываем массив и в квадртаных скобках номер значения в нем. Счет начинается с нуля:
tasks[0] = 39
companies[0] = 15
companies[1] = 20Простой массив в form-data Проверяем, что наши пользователи есть в интерфейсе:
Сложный массив
Его мы найдем в методе CreateUserWithTasks — задачи создаются в виде массива значений.
В json формате:
<
«email»: «test_cu_22@mail.com»,
«name»: «Рестовый 22»,
«tasks»: [ <
«title»: «Первая задача»,
«description»: «Первая задача 11»
>,
<
«title»: «Вторая задача»,
«description»: «Вторая задача 11»
>
],
«companies»: [15, 20]
>Сложный массив в json В form-data:
tasks[0][title] = Заголовок задачи 1
tasks[0][description] = Описание задачи 1tasks[1][title] = Заголовок задачи 2
tasks[1][description] = Описание задачи 2Сложный массив в form-data То есть мы указываем сначала, какой по счету элемент массива tasks идет (отсчет начинается с нуля), а потом без точки или пробела в квадратных скобках указываем поле этого элемента.
Находим юзера в интерфейсе, проверяем — да, задачи создались!
Как-то так
PS — статья написана в помощь студентам моего курса «Тестирование REST API». Заходите на огонек!