Даже успешный ответ относится к правам конкретного подключения. Разбираем, как отличить ограниченную область доступа от потерянных страниц выгрузки.
Успешный ответ ещё не описывает весь источник
Представим условную компанию с несколькими рабочими проектами. В её системе есть заявки разных подразделений, а подключение для отчёта получило доступ только к двум из них. Загрузка завершилась без ошибок и вернула правдоподобный список. Если читатель ожидает сведения по всей компании, неполный охват легко принять за отсутствие заявок в остальных подразделениях.
API — программный интерфейс, через который системы обмениваются данными. Полнота ответа зависит не только от того, удалось ли получить все порции, но и от области доступа подключения. Для нашего примера важно различать два утверждения: «получено всё разрешённое этому подключению» и «получено всё необходимое для отчёта». Первое не доказывает второе.
Подключение действует от определённого имени
Токен доступа — служебное подтверждение, с которым приложение обращается к системе. Он связан с разрешениями и не обязан повторять возможности администратора, открывшего сайт в браузере. Поэтому сравнение «я вижу больше в интерфейсе» ещё не показывает поломку загрузки. Сначала нужно понять, чьи полномочия применяются при автоматическом обращении.
Например, документация GitHub о списке репозиториев пользователя связывает возвращаемые ресурсы с его доступом. Репозиторий — место хранения материалов проекта. Это конкретный пример устройства API, а не правило для любого сервиса. В собственной системе нужно читать описание именно выбранного способа получения данных.
Права приложения тоже имеют границы
В руководстве GitHub для установленного приложения доступ ограничен разрешёнными ресурсами и полномочиями установки. Токен можно дополнительно сузить, но он не получает права за пределами установки. Пример показывает, почему одного названия приложения недостаточно для объяснения того, какие данные оно увидит.
Вернёмся к условным заявкам. Предложим составить перечень нужных подразделений и попросить владельца источника подтвердить, какие из них входят в область подключения. В документе достаточно описать назначение, охват и ответственного. Сам токен туда помещать не нужно. Если недостающая часть не разрешена для этой задачи, исправлением будет уточнение отчёта, а не требование выдать полный административный доступ.
Сначала проверить ожидаемую область, потом количество
Допустим, по согласованному перечню отчёт должен охватывать три подразделения. Для каждого предложим выбрать заранее известную учебную заявку и проверить её присутствие. Если примеры из двух подразделений находятся, а из третьего нет, это повод исследовать границу доступа, выбранную организацию и фильтры. Такой результат ещё не доказывает единственную причину пропуска.
Затем проверим временной период и условия отбора. Архивные заявки могут исключаться самим способом получения данных. Количество строк полезно как контрольный сигнал, но одинаковые числа не гарантируют одинакового состава. Для нашего разбора важны конкретные ожидаемые записи и объяснение, почему они должны входить в набор. Все заявки и подразделения здесь вымышлены.
Не путать ограничения доступа с неполной доставкой
Если подключение видит нужную область, следующая проверка — получение всех страниц API. Пагинация означает выдачу списка порциями. Перебор страниц не расширяет права, а дополнительные права сами по себе не заставляют загрузку дочитать продолжение. Эти две причины неполноты требуют разных действий.
После получения данных полезна сверка источника и отчёта. В пояснении к результату укажем фактический охват, момент проверки и известные исключения. Начинающему инженеру важно уметь объяснить границу набора словами прежде, чем искать ошибку в обработке. Разобраться в таких задачах поможет программа Data Engineer для начинающих.
