Вложенные ответы API: спуск по этажам до нужного поля

Пять дней прогноза для дачного узла на ESP32 я забирал одним запросом: сервис отдавал около семи килобайт, сорок записей list, и температура в каждой записи лежала не на верхнем этаже, а внутри вложенного объекта temp. В мониторе вместо ожидаемых минус восьми градусов печаталось 0.00 — без единой жалобы со стороны разбора. Я трижды перепроверял ключи, пока не посчитал этажи: doc["list"][3]["temp"]["day"] — четыре пары скобок, и каждую пару я обязан пройти по очереди. Промах на любой из них не роняет скетч и не срывает разбор — он подставляет ноль, и устройство молча живёт с выдуманной погодой.

Механику цепочек мы уже разбирали в уроке про вложенные объекты и в уроке про список объектов из API; здесь цель другая — собрать полный маршрут по живому ответу сервиса погоды, где массив, объект и снова массив чередуются через этаж. Заодно закрою типовую граблю инструкций про OpenWeather: почти каждая из них показывает doc["main"]["temp"] для текущей погоды и молчит о том, что в прогнозе та же температура спрятана на два этажа глубже — и ключ там уже не temp наверху, а day внутри вложенного объекта. Смешать эти два формата — типовое начало вечера отладки: скетч с текущей погоды переносят на прогноз, и половина маршрутов перестаёт сходиться.

План такой: анатомия многоэтажного ответа со счётом слотов, итерация по списку записей с фильтром по дате, затем симулятор — с честной оговоркой, какой этаж он видит, а какой остаётся механикой настоящей платы.

Этажи бывают трёх сортов: объект внутри объекта, массив внутри объекта и объект внутри массива. Нотация у всех одна — каждая пара квадратных скобок или каждое имя после точки опускает вас на один уровень вниз, и читать цепочку надо слева направо, как маршрут на маршрутке: пересадки по порядку, без прыжков через остановку. В ответе сервиса погоды объект main держит измерения текущего часа, массив weather — текстовое описание неба, а в прогнозе те же измерения лежат в списке list, где каждая запись — самостоятельный объект со своим temp и своим weather. Ноль в конце цепочки почти всегда значит, что вы сошли не на тот этаж или перепутали лестницу. Я вычерчиваю маршрут на бумаге до кода: скобочный путь на три этажа проще вычеркнуть глазами, чем ловить в мониторе по нулям.

Массив weather стоит отдельного абзаца: сервис почти всегда кладёт туда один элемент, но формат — именно массив, рассчитанный на несколько явлений разом, скажем дождь с грозой одновременно. Отсюда классический промах: обращение doc["weather"]["main"] без индекса компилируется, выполняется и возвращает ноль — вы просите у массива поле, которого у него нет и быть не может. Правильная лестница — doc["weather"][0]["main"], и индекс 0 здесь не перестраховка, а честное согласие с форматом. Проверять это согласие нужно один раз при смене API, а не в каждом цикле. В моём журнале промахов половина была именно тут: индекс выбрасывают, когда элемент виден один, и формат перестают читать как формат.

Глубина стоит памяти: каждый этаж добавляет слоты в пул документа, и прогнозный ответ на сорок записей с тремя уровнями вложенности просит заметно больше, чем плоский пакет с теми же значениями. Как считать эти байты и сколько просить у платы — раскладывали в уроке про расчёт ёмкости; здесь добавлю практическое следствие: если вам нужны только дневные температуры, берите фильтром один этаж temp и не тащите весь list целиком — механика фильтров была в уроке про разбор нужных полей. Фильтр срежет и память, и время разбора: парсер не станет раскладывать записи, которые вы всё равно выбросите.

Число записей сервис держит в ключе cnt наверху, но доверять константе я не привык: запрос с параметром count=3 вернёт три записи, и цикл с жёсткой сороковкой уедет в пустоту, читая нули с несуществующих этажей. Честный способ — size() на самом массиве: doc["list"].size() возвращает текущую длину, и цикл подстраивается сам, хоть сервис режет прогноз, хоть разворачивает до сорока. Внутри каждая запись — объект, и к её этажам обращение то же, что и к одиночному ответу: doc["list"][i]["temp"]["day"] за дневной температурой, doc["list"][i]["weather"][0]["main"] за описанием неба. Имена этажей внутри записи совпадают с именами одиночного ответа — привычка переносится без переучивания.

Записи идут с шагом три часа, и для будильника «одеть рассаду» мне нужна была только полуденная: поле dt_txt хранит строку с датой и часом, из неё достают подстроку с полуднем и сравнивают — механика строковых сравнений та же, что при разборе команд из монитора в уроке про приём по ограничителю. Альтернатива — считать индексы: полдень сидит на позициях 4, 12, 20 при шаге в три часа, и цикл просто прыгает через восемь записей. Способ дешевле сравнений, но хрупче: сервис сменит шаг прогноза — и прыжки уедут мимо полудня. Универсальный компромисс — сравнение по подстроке, а шаг оставляю для грубой прикидки индексов.

Чем длиннее цепочка, тем дороже отладка, поэтому я печатаю промежуточные этажи: сначала doc["list"][i]["temp"] целиком через serializeJson, потом конкретное поле. Две строки печати экономят вечер — сразу видно, на каком этаже вы сошли с лестницы. Для массивов внутри массивов, скажем почасовой разбивки внутри дня, механика та же: её раскладывали в уроке про массивы массивов. Приём один и тот же: спуск по этажам, замер size(), цикл по индексу.

Движок книги эмулирует разбор, чтение верхних ключей и доступ к массиву чисел по индексу — doc.t[i] работает; цепочки на три этажа вроде doc.list[i].temp.day он не опускает и вернёт ноль, что мы честно проверили заранее. Поэтому прогнозный пакет в симуляторе сплющен: город и влажность наверху, температуры — массивом t на верхнем этаже. Логика урока при этом цела: обходим записи по индексу, ищем минимум и максимум, вердикт отдаёт LED на D12. Пакет при этом полный: город, влажность, четыре температуры — сплющен формат, а не содержание.

Смотрите на вывод монитора как на трассировку лестницы: razbor=1 — разбор прошёл, дальше по строке на каждый день. На настоящей плате вместо плоского массива работает цепочка из code-блока выше — она проверена на Uno с седьмой версией библиотеки и на ESP32 с шестой. Если движок и плата разойдутся в цифре, приоритет у платы: симулятор — тренажёр маршрута, а не замена железа.

Следующий шаг после спуска по этажам — не доверять пройденному без проверки: пакет мог прийти синтаксически чистым, но без нужного ключа или с текстом вместо числа, и молчаливый ноль вернётся с чёрного хода. Как стоит заслон из containsKey, is и as — третий урок: валидация входящего JSON. Домашнее задание: возьмите свой сервис с вложенным ответом — прогноз, телеметрия, расписания — и выпишите на бумаге лестницу до каждого нужного поля с числом этажей; половина нулей в мониторе исчезнет уже от одной такой таблицы. Число этажей в таблице заодно подскажет, стоит ли просить фильтр: чем меньше лестниц, тем дешевле разбор на восьмибитной плате.