Как работает JSON и как передается информация с его помощью?
Что проверяют
Умеете ли вы читать и проверять JSON как тестировщик: видеть типы, структуру и места, где ломается интеграция. Следом часто дают кусок JSON с ошибкой или просят рассказать, как вы проверяете ответ API.
Как отвечать
JSON это текстовый формат обмена данными, описанный в RFC 8259. Значение бывает одного из шести типов:
- объект: пары «ключ: значение» в фигурных скобках, ключ всегда строка в двойных кавычках;
- массив: упорядоченный список в квадратных скобках, элементы могут быть разных типов;
- строка: только двойные кавычки, спецсимволы экранируются обратным слэшем;
- число: без кавычек, без ведущих нулей, без
NaNиInfinity; - логическое значение и пустое:
true,falseиnull.
Отдельного типа для даты нет, её передают строкой, обычно в ISO 8601. Комментарии и висячие запятые стандарт не допускает, кодировка при обмене между системами UTF-8.
Передача устроена так: отправитель сериализует объект в строку (JSON.stringify, json.dumps, Jackson в Java), кладёт её в тело HTTP-запроса или ответа с заголовком Content-Type: application/json, получатель разбирает строку обратно в объект. Тело обычно есть у POST, PUT, PATCH и у ответов, а у GET параметры идут в строке запроса.
Что проверяете вы: код ответа, заголовок Content-Type, соответствие схеме (JSON Schema в Postman или в автотестах на Rest Assured, pytest), типы и обязательность полей, граничные значения, кириллицу. В негативных сценариях отправьте битый JSON и неверный Content-Type: корректный сервер ответит 400 или 415, а не 500.
Где спотыкаются
Не различают отсутствующее поле, поле со значением null и пустую строку или пустой массив. Для клиента это разные случаи, и баги живут именно здесь.
Не проверяют типы: "42" вместо 42 или "true" вместо true на глаз похожи, но ломают клиентский код.
Не знают про точность чисел. JavaScript без потерь хранит целые только до Number.MAX_SAFE_INTEGER, поэтому длинные ID из базы на фронте молча искажаются. Их принято передавать строкой, и это стоит проверять.