API Testing from Entry Level to PhD - Jason Ioannides

#testing #api

Доброго дня!

Сьогодні до Вашої уваги пропоную цікаву доповідь про те, що таке API, які вони бувають та що відбувається "під капотом".

Відео допоможе трохи глибше зануритися у світ API. (Але все ще без хардкору).

Приховане перетворення даних в grpcui та k6

#testing #api #tools #python

Ситуація
Для одного з наших gRPC сервісів нам потрібно відправити hash у форматі HEX. Але коли я намагався відправити запит за допомогою grpcui або ж у скрипті навантаження k6 - сервер повертав помилку, що такий хеш не знайдений в нашій базі.

Задача
Треба було розібратись, у чому причина перетворення даних - та де криється проблема. Бо сервіс точно працював правильно.
Значить проблема в роботі інтрументів ...

Рішення
Як виявилося - обидва інструменти очікують вхідні дані в base64. Потім вони декодують ці дані та надсилають результат на сервер.
В Python з base64 працювати дуже легко. То ж у нагоді стане наступний скрипт.

import base64


def from_b64_to_hex(input):
    binary_data = base64.b64decode(input)
    return binary_data.hex()


def from_hex_to_b64(input):
    binary_data = bytes.fromhex(input)
    return base64.b64encode(binary_data).decode()


base64_string = "LxTKPCw9jAv1U8Xm6lxjhtGlnoZzNPc6I="
hex_string = "2f14ca3c2c3d880653b15e6ea5c6386d1a59e867334f73a2"

assert hex_string == from_b64_to_hex(base64_string)
assert base64_string == from_hex_to_b64(hex_string)

І ще одне
Крім цього скрипта, можна скористатись також безкоштовним онлайн конвертером.

Про JSON-RPC та як його тестувати

#testing #api

Коли я прийшов працювати в блокчейн - то побачив, що доволі багато різних продуктів мають інтеграцію через API. Але то було не звичне усім HTTP REST API. Це було - JSON-RPC API.
Тому сьогодні поговоримо про те, що таке JSON-RPC та як його тестувати.

Що таке RPC?
RPC (Remote Procedure Call) - віддалений виклик процедур. Це протокол з далеких 1970х років, що дозволяє викликати процедури на іншому ком'ютері ніби-то процес знаходиться на вашому ком'ютері. Більше - ось тут.

Що таке JSON-RPC?
Якщо коротко, це протокол для віддаленого виклику процедур, побудований за специфікацією. Він розділяє бізнес логіку та від саме передачі даних. Запити йдуть через HTTP POST у форматі JSON.
Формат запиту та відповіді в JSON-RPC - стандартизований, та складається з декількох обов'язкових полів.
Запит (приклад Ethereum API)

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance",
"params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}'

- "jsonrpc" - індикація, що це саме jsonrpc. Зазвичай використовується версія 2.0
- "method" - ім'я віддаленого методу (аналог ендпоінту в REST)
- "params" - об'єкт або ж массив параметрів для методу
- "id" - унікальний ідентифікатор запита

Відповідь

{
  "id":1,
  "jsonrpc": "2.0",
  "result": "0x0234c8a3397aab58" // 158972490234375000
}

- "jsonrpc" - також "2.0"
- "result" - об'єкт відповіді
- "error" - об'єкт помилки, що складається з полів code, message та data
- "id" - такий же, як і в запиті

Які бувають коди помилок в JSON-RPC
- '-32700' - Parse error (сервер не зміг розпарсити запит)
- '-32600' - Invalid Request (JSON у запиті - невалідний)
- '-32601' - Method not found
- '-32602' - Invalid params
- '-32603' - Internal error (внутрішня помилка JSON-RPC)
- '-32000' to '-32099' - Server error

JSON-RPC - транспортно незалежний протокол. Тобто він може працювати як з HTTP,
так і з TCP чи веб сокетами. HTTP - частіше. Плюс - протокол підтримує як синхронні, так і асинхронні виклики.

Як та чим тестувати JSON-RPC API?
Коротко - так само, як ви тестуєте будь-яке інше звичне API. Робите запит, отримуєте відповідь.
- Якщо відповідь успішна - поле result буде з даними.
- Якщо трапилася проблема - перевіряйте поле error.

Тому тестувати можна будь-яким зручним інструментом, типу: Postman, Insomnia чи cURL.
Для прикладу - API від Ethereum.

Як бачите - нічого страшного.

Таємниче життя вашого API

#testing #api

З чого все почалося

Цього тижня я проводив експерименти з тим, як працює наша система з блоками різної довжини. Для цього я знайшов вбудований інструмент (Glutton pallet), який дозволяє заповнювати обрати наскільки заповнювати блоки "сміттєвою" інформацією. Конкретно - блоки заповнюються масивами 8-бітних чисел.

Тестування було простим - заповнити блок, скажімо на 2 Mb випадковими бінарними даними й подивитись наскільки швидко він розповсюджується по мережі. Активація інструменту виконується на рівні коду, але ліміти на заповнення можна встановлювати через зручний UI. Встановивши розмір заповнення в 2 Mb, я дивився на моніторинг й робив необхідні вимірювання.

Але для перевірки, я вирішив зробити простий JSON-RPC запит окремого випадкового блоку через Postman. Ось тут почалася магія.

Postman показав мені відповідь від серверу, але розмір body був не 2 Mb, а ...4 Mb. Я спробував декілька інших блоків, але з тим самим результатом.
Я встановив розмір блоку в 1 Mb - response в Postman був розміру 2 Mb. Але ... чому?

Відповідь

Інструмент для замірів працював корректно. Але виявилось, що кожного разу коли ми робимо запит на JSON-RPC то під капотом результат автоматично кодується за допомогою SCALE кодека. Кожен байт в бінарному форматі кодується як два HEX символи. Тобто масив з 1024 байтів на виході буде мати аж 2048 символів. Причому кодування виконується "під капотом" самого вузла.

Висновок

Не завжди дані, які ми бачимо API відповіді від серверу показані саме так, як вони реально зберігаються в системі.