Какие типы могут быть ключами в JSON

Что проверяют

Короткий вопрос на знание формата: ключ в JSON только строка. Интервьюеру интересно, знаете ли вы, откуда берётся путаница с числами и что происходит с дублями и порядком ключей, потому что это прямо влияет на проверки в API-тестах.

Как отвечать

По спецификации (RFC 8259, ECMA-404) имя поля объекта это строка в двойных кавычках. Любая: пустая "", с пробелами, с кириллицей, с экранированными символами. Числа, true, null, массивы и объекты ключами быть не могут.

Дальше разберите тонкие места:

• путаница с JavaScript: в объекте JS можно написать {1: "a"} или {name: "a"} без кавычек, но это синтаксис языка, а не JSON. Строгий парсер такой текст отвергнет, как и одинарные кавычки или запятую после последнего поля;
• сериализация чисел: json.dumps({1: "a"}) в Python выдаст {"1": "a"}, и после обратного разбора ключ станет строкой. Отсюда баги вида «отправили число, получили строку»;
• дубли: спецификация говорит, что имена должны быть уникальными, но поведение при дублях не определяет. JSON.parse и модуль json в Python берут последнее значение, другие парсеры могут вернуть ошибку;
• порядок: он не гарантирован, поэтому сравнивать ответы как строки нельзя, только как структуры;
• регистр: id и ID это разные ключи.

В API-тестах ключи проверяют через JSON Schema: required для обязательных полей, additionalProperties: false против лишних, propertyNames для формата имён.

Где спотыкаются

Отвечают «ключом может быть число», потому что в JS-объекте это работает. Это объект языка, а не формат обмена данными.

Сравнивают ожидаемый и фактический ответ как строки. Тест падает от перестановки ключей, хотя данные совпадают. Нужно сравнение структур: распарсить ответ и сравнить объекты или взять библиотеку вроде JSONAssert.

Не проверяют дубли в ответе. Сервер, который отдаёт "status" дважды, работает только потому, что клиентский парсер молча берёт последнее значение, а другой клиент на том же ответе упадёт.