JSON по HTTP: получаем и разбираем ответ

Тепличный датчик на ESP32 раз в десять минут ходил в погодный API, и разбор ответа я собрал по-рабочему, как умел: нашёл в теле слово temp через indexOf(), отступил шесть символов и вырезал четыре до запятой. Неделю на табло было ровно то, что нужно. Потом ударили заморозки, температура ушла в минус — и минус занял один символ, которого моя вырезка не ждала. Табло показывало 2.5 с хвостом из кавычек, хотя за окном было -12.5. Час я искал виновника в датчике, а сидел он в одной строке substring.

Дело не в кривых руках, а в подходе: indexOf() читает текст по позициям, а позиция — вещь ненадёжная. Знак числа, лишний пробел, переставленные сервером поля — любая мелочь сдвигает вырезку на символ. Строка с сервера не текст для резать, а документ со структурой: город, температура, описание — каждый со своим именем. Библиотека ArduinoJson читает структуру, а не позиции, и минус ей безразличен.

Здесь собираем полную связку: GET-запрос из урока про HTTP-запросы плюс честный разбор через deserializeJson. Разберём, сколько памяти съедает тело ответа вместе с документом, когда вместо getString() брать поток, и что делать с кодами разбора. Синтаксис JSON и устройство JsonDocument по косточкам разбирались в разделе про ArduinoJson — здесь ставим их на сетевые рельсы.

Демо-ответ, который ходит по этой странице, выглядит так: {"city":"Moscow","temp":18.5,"desc":"Малооблачно"}. Сорок пять байт, три ключа, два типа значений: city и desc — строки в кавычках, temp — число без кавычек. Ничего лишнего, и именно такой размер ответа я считаю здоровым для железного проекта: один запрос — одна строка, всё видно глазами в мониторе порта.

Гибкость формата — то, что ломает ручные вырезки. Сервер вправе переставить поля без предупреждения, добавить wind между temp и desc, отдать температуру строкой "18.5" вместо числа 18.5 — разбор переживёт всё это, потому что читает имена, а не позиции. Правила синтаксиса и четыре типа значений я подробно разбирал в уроке про синтаксис JSON — там же про то, почему одинарные кавычки невалидны.

Про память сразу с числами. У документа есть ёмкость, и моё правило — закладывать в полтора-два раза больше длины ответа: для 45 байт берём 128, с запасом на новые поля — 256. На ESP32 с его 520 КБ RAM это не вопрос вовсе, я ставлю 768 и не думаю. Отличия версий библиотеки и установка через менеджер — в материале про установку ArduinoJson 7; в старых туториалах вы встретите StaticJsonDocument<256> — то же самое с ручным лимитом.

Разбор по косточкам. Три include — WiFi для сети, HTTPClient для запроса, ArduinoJson для разбора; последняя ставится из Менеджера библиотек за минуту. addHeader() встаёт между begin() и GET(): в живых API заголовок User-Agent иногда проверяют, и клиент без имени часть сервисов молча отсекает. Сам запрос возвращает код — 200 означает, что тело можно забирать.

Теперь честная арифметика памяти. getString() кладёт ответ в String — для 45 байт это мелочь. Но вместе с документом на 768 байт тело лежит в RAM дважды: копия строкой и копия в разобранном виде. На ESP32 сумма незаметна, а вот на Uno с её 2 КБ уже тесно. У библиотеки есть ход лучше: deserializeJson(doc, http.getStream()) — парсер читает из потока сети сам, без промежуточного String, и память тратится один раз. Для ответов в килобайт и больше я беру только этот вариант — String такого размера успевает наделать дыр в куче за сутки опросов. И про терпение: если сервер задумался, выручает http.setConnectTimeout(5000) — через пять секунд GET вернёт -1, и loop хотя бы не встанет навсегда; без этой строчки я однажды ждал ответа целую минуту.

Идиома if (err) выглядит непривычно: тип DeserializationError устроен так, что любое значение кроме Ok приводится к истине. Без этой проверки срыв разбора проходит молча: документ остаётся пустым, и каждое чтение doc["temp"] вежливо вернёт ноль — табло покажет 0.0 и ни словом не обмолвится. Моё правило: err.c_str() в Serial сразу после разбора, даже в одноразовом скетче для стола. Имя кода в логе — InvalidInput, NoMemory или IncompleteInput — экономит час гадания, а приёмы ведения такого лога одни и те же для любого железа, я собирал их в уроке про отладку через Serial.

Сеть в симуляторе эмулируется честно: WiFi.begin подключает плату за секунду-полторы, GET возвращает 200, а getString отдаёт демо-тело с городом, температурой и описанием. Все шаги живого скетча на месте — от статусного цикла до вердикта по температуре, меняется только то, что сервер тут учебный.

Одна оговорка про движок: чтение полей он понимает в точечной форме — doc.temp, doc.desc. В библиотеке скобки и точка равнозначны: doc["temp"] и doc.temp на плате делают одно и то же, пишите как удобнее. Проверку ошибки движок отдаёт числом: 1 — разбор удался, 0 — провал; на плате то же место занимает DeserializationError с if (err). Смысл проверки один и тот же, а в code-блоке выше остались именно скобки — как на живой плате.

В логе виден весь путь данных: тело пришло строкой, разбор вернул 1, значения легли по именам, и решение про проветривание плата приняла сама — без единого indexOf(). Если убрать проверку ok, поведение скетча не изменится ровно до первого кривого ответа: движок вернёт 0, документ останется пустым, а чтения дадут нули — та самая тихая ловушка из таблицы кодов. Проверьте и вторую сторону: временно подмените адрес на несуществующий — на живой плате GET вернёт -1, разбор даже не начнётся, и станет ясно, что дело в сети, а не в JSON.

Один запуск — мало. Перезапустите симулятор два-три раза и посмотрите на тайминги: подключение занимает пару секунд, ответ приходит с задержкой полсекунды — это нормальный ритм для живого API, а не подвисание. По этому ритму на реальной плате вы отличите медленный сервер от умершего соединения за первые же сутки наблюдений.

Теперь плата умеет не только спрашивать, но и понимать ответ: строка с сервера превращается в числа и решения, а минус в температуре больше никого не пугает. Тепличное табло после переезда на deserializeJson пережило и перестановку полей, и первый минус, и добавление ветра в ответ сервера — к разбору я больше не возвращался ни разу.

Дальше разворачиваем роли: в следующем уроке плата сама станет сервером — библиотека WebServer.h, маршруты server.on и первая HTML-страница, которая живёт прямо в скетче, а браузер ходит к плате сам. А если данные нужны не вам, а другой технике, тот же приём отдачи JSON пригодится в MQTT на ESP32 — там плата публикует показания брокеру, и разбирает чужие ответы он уже без нас.