Корректные входы могут означать разное
JSON может быть объектом, массивом или простым значением. null допустим, даже если контракт требует объект. Некоторые числа выходят за целочисленную точность JavaScript; повторные имена свойств разные парсеры трактуют неодинаково.
| Демонстрационный вход | Синтаксическое чтение | Оставшаяся проверка |
|---|---|---|
| {"ok":true} | Корректно. | Соответствует ли значение контракту? |
| {"ok":true,} | Некорректно: завершающая запятая. | Явно обработать ошибку. |
| null | Корректно. | Разрешает ли контракт null? |
| {"id":9007199254740993} | Корректное число, риск точности в JavaScript. | Предусмотреть строку для идентификатора. |
| {"a":1,"a":2} | Повторные имена: непереносимая трактовка. | Определить и применить правило отклонения. |
Контролировать каждый этап приёма
- Используйте поддерживаемый JSON-парсер, никогда eval. Проверяйте HTTP-статус, ожидаемый тип содержимого, размер и явную обработку пустого или повреждённого тела.
- Затем проверяйте контракт: корневой тип, обязательные поля, допустимые значения и разницу между отсутствием, null и нулём. Длинные идентификаторы храните строками, если таков контракт.
- Задайте ограничения глубины и ресурсов, политику повторных имён и ошибки. Не вставляйте полученные строки в HTML или запросы без подходящей защиты.
Сохранять полезные ошибки без раскрытия данных
Тестируйте частичные ответы, смену версий и Unicode. Записывайте минимальный контекст вместо секретов или полного тела. Ошибка декодирования не должна превращаться в пустой успешный результат или незаметно останавливать всю цепочку.
Первоисточники
Регистрируйте ошибки JSON API без утечки полезной нагрузки.
Тело JSON может содержать идентификаторы, секреты или персональные данные. Для диагностики часто требуется тип события, маршрут, результат, идентификатор корреляции и неконфиденциальная информация о сбое, а не полная полезная нагрузка.
- Классифицируйте поля и маскируйте те, которые не нужны для диагностики.
- Проверяйте сбои парсинга и схемы с помощью синтетических значений.
- Убедитесь, что журналы ошибок и экспорт не копируют полные полезные нагрузки.
Первичный источник: ACSC and partners — Event logging and threat detection. Связанный метод: прочитать практическое руководство.
Персонализированные ключи JSON и кэша
Дополнительный пункт проверки: персонализированные ключи JSON и кэша. Политика на уровне представления и тесты, выявляющие утечку данных между учетными записями и устаревшее содержимое после изменений.
- Выберите срок хранения: RFC 9111 различает директивы: no-cache требует проверки перед повторным использованием, no-store запрещает соответствующее хранилище HTTP, а unqualified private исключает общее хранилище. Ни одна из них сама по себе не гарантирует конфиденциальность системы.
- Проверка ключей: проверьте метод, URI и параметры, изменяющие представление. Изменения касаются полей запроса; это не авторизация. Найдите пропущенные языковые параметры, согласование формата и контекст учетной записи на уровне приложения.
Первичный источник: IETF — RFC 9111, HTTP Caching. Связанный метод: прочитать практическое руководство.
Пагинация API и целостный экспорт
Изменяющийся набор может приводить к пропускам и повторениям.
- Запишите фильтры, сортировку и ключ для одинаковых значений. Уточните, даёт ли API снимок или изменяемую коллекцию. Проверьте создание и удаление во время чтения: наличие курсора не гарантирует неизменность данных.
- В AIP-158 чтение завершает пустой next_page_token, а не короткая или пустая страница результатов. Вымышленные страницы [A,B] и [B,C] содержат четыре строки, но три уникальных идентификатора. Выявляйте повтор курсора без продвижения и соблюдайте контракт используемого API.
- Надёжно сохраните пакет до подтверждения продолжения. Повторите прерванный пакет по стабильным идентификаторам и проверяйте права при каждом запросе: курсор не даёт доступа. Если снимок истёк, начните заново или явно сверяйте; не объединяйте разные состояния молча.
Воспроизводимый приёмочный случай
Вымышленный пример: данные не описывают клиента или наблюдаемый результат.
Посмотреть данные случая
{
"page_1_ids": [
"A",
"B"
],
"page_2_ids": [
"B",
"C"
],
"next_cursor": "c2",
"empty_page_has_next_cursor": true
}Ожидаемое решение
B повторяется. Проверьте идентификаторы и продолжайте по курсору даже после пустой страницы.
Процедура проверки
- Определите фильтры, устойчивый порядок и идентичность.
- Проверьте дубль и пустую страницу с курсором.
- Сохраните идентификаторы и настоящее условие завершения. Сопоставьте полученные объекты и уникальные идентификаторы; отмечайте повтор курсора, не считая пустую страницу с продолжением концом сбора.
Доказывает ли ожидаемое число строк полноту выгрузки?
Нет. Пропущенный и повторный идентификаторы могут взаимно компенсироваться в количестве. Сверьте идентификаторы, область и отсечку и запишите нерешённые различия.
Первичный источник: Google AIP-158 — Pagination. Связанный метод: прочитать практическое руководство.