Не вдалося розпарсити відповідь: як полагодити цей збій

Повідомлення «Не вдалося розпарсити відповідь» з’являється раптово, ніби хтось висмикнув розетку зсередини програми. Сайт малює порожню картку замість замовлення, чат із помічником застигає на півслові, каса в магазині «думає» над оплатою і нічого не друкує. За цим коротким рядком ховається цілком конкретна технічна відмова: клієнт отримав байти, але не зміг перетворити їх на структуру, яку вміє читати. Людина в цей момент тисне ту саму кнопку ще раз, хоча повтор рідко лікує зламану граматику даних. Нижче розберемо, звідки береться цей глухий кут і як із нього вийти без шаманства.

Парсинг — це не магія і не «поломка інтернету». Це граматичний розбір: програма чекає JSON, XML або інший чіткий формат, а натомість дістає HTML-сторінку помилки, обрізаний фрагмент, порожнє тіло або текст із «кривими» лапками. Українською «розпарсити» прийшло з англійського parse — аналізувати рядок за правилами граматики. Словник IT-сленгу вже давно зафіксував це дієслово як робочий термін розробників.

Нижче — повна карта збою для початківців і для тих, хто пише API. Ви отримаєте алгоритм діагностики, швидкі кроки без коду, глибокі виправлення для бекенду, окремий розбір ШІ-чатів, ботів і касових систем. Додамо чек-лист, типові помилки й живий міні-кейс, щоб ця фраза більше не з’являлась у логах о другій ночі. Мета проста: вийти з режиму «нічого не відкривається» в режим «я знаю, який саме шар збрехав».

Зміст

Що ховається за формулюванням «не вдалося розпарсити відповідь»

Клієнт і сервер спілкуються не «людською» мовою, а контрактом. Сервер обіцяє віддати дані у визначеному форматі, клієнт обіцяє цей формат розібрати. Коли контракт порушено, парсер піднімає руки: синтаксис не збігається з очікуваною граматикою. Саме тоді інтерфейс показує «Не вдалося розпарсити відповідь» замість нормального вмісту. Без цього контракту навіть ідеальний інтернет перетворюється на німий кабель: байти є, сенсу немає.

Найчастіше на кону стоїть JSON — легкий текстовий формат обміну, закріплений стандартом RFC 8259 і специфікацією ECMA-404. Він терпить лише подвійні лапки, забороняє кому після останнього елемента, не любить коментарів і вимагає кодування UTF-8. Документація MDN Web Docs (developer.mozilla.org) прямо каже: JSON.parse() кидає SyntaxError, щойно рядок відхиляється від цих правил. Один зайвий символ на початку — і вся відповідь стає сміттям для програми.

Помилка парсингу відрізняється від мережевої. Мережа може чесно сказати «немає зв’язку» або «таймаут». Тут зв’язок часто вже відбувся, статус інколи навіть 200, а «начинка» відповіді непридатна. У нашій практиці ми стикалися з таким випадком, коли мобільний застосунок роками працював ідеально, поки CDN не почав віддавати HTML-заглушку технічних робіт замість JSON. Користувач бачив лише червоний рядок. Розробник бачив перший символ «<» — візитну картку HTML замість об’єкта.

Важливо розвести ще дві плутанини. «Не вдалося розпарсити відповідь» — це не те саме, що «невалідний логін», і не те саме, що «сервер упав». Це шар посередині: транспорт доставив щось, інтерпретатор не зрозумів що. Поки ви не подивитесь на сире тіло відповіді, будь-які здогадки про «глючний телефон» залишаться гаданням на кавовій гущі. Телефон тут лише вітрина; ламається текст, який ця вітрина намагається прочитати.

Технічні причини, через які парсер здається

Перша класика — сервер віддав HTML, а клієнт чекав JSON. Шлюз, проксі або балансувальник при кодах 502, 503 чи 504 малює сторінку «Service Temporarily Unavailable». Парсер бачить «

» і падає з повідомленням на кшталт Unexpected token < in JSON at position 0. Те саме трапляється, коли сесія протухла і замість API прилітає HTML-форма логіну.

Друга група причин живе всередині самого JSON. Зайва кома після останнього поля, одинарні лапки замість подвійних, ключі без лапок, коментарі у стилі JavaScript, зламані екранування слешів, «розумні» типографські лапки замість прямих. JavaScript-об’єкт у коді пробачає багато з цього. JSON — ні. Різниця болюча саме тому, що око розробника бачить «майже правильний» текст, а парсер бачить порушення граматики.

Третя група — обрив і порожнеча. Потік обірвався на півслові, проксі відрізав тіло за таймаутом, клієнт викликав JSON.parse(“”) або JSON.parse(undefined). У другому випадку рушій перетворює undefined на рядок “undefined” і скаржиться на unexpected token u. Об’єкт, який уже розібрали один раз, дає token o — від “[object Object]”. За моїм досвідом супроводу інтеграцій протягом місяця саме ці три «літери» — <, u, o — закривають левову частку нічних інцидентів.

Четверта пастка — кодування. Стандарт RFC 8259 вимагає UTF-8 для JSON, яким обмінюються відкриті системи, і не рекомендує BOM. Файл, збережений «UTF-8 with BOM» у Windows-редакторі, починається невидимим символом U+FEFF. Парсер читає його як сміття на позиції 0. Додайте сюди Windows-1251 замість UTF-8 у старих облікових системах — і кириличні назви товарів перетворюються на ламаний потік, який уже ніхто не збере.

Симптом у повідомленні	Що насправді прийшло	Типове джерело	Перший крок
Unexpected token <	HTML-сторінка замість JSON	502/503, логін, заглушка CDN	Відкрити сире тіло й код статусу
Unexpected token u	Рядок “undefined”	Порожня змінна перед parse	Перевірити, чи є тіло відповіді
Unexpected token o	Вже розібраний об’єкт	Подвійний JSON.parse	Подивитись typeof перед розбором
Unexpected end of data	Обрізаний JSON	Таймаут, стрім, ліміт проксі	Повторити запит і порівняти Content-Length
Unexpected token , або ‘	Невалідний синтаксис JSON	Зайва кома, одинарні лапки	Прогнати тіло через валідатор

Після таблиці не поспішайте «виправляти JSON вручну в голові». Збережіть тіло як файл і проженіть його через валідатор: якщо валідатор червоний, клієнт має рацію. Типологія симптомів спирається на усталені повідомлення рушіїв JavaScript і на щоденну практику діагностики HTTP API. Таблиця не вичерпує всі коди Firefox, V8 і Safari, але закриває ті, що реально спливають у логах браузера, Node.js і мобільних клієнтів.

Де ця помилка спливає в реальному житті

Вебінтерфейси інтернет-магазинів люблять ховати парсинг за кнопкою «Оформити». Користувач натискає, крутиться спінер, і раптом — порожня модалка. Часто винен WAF або антибот: він віддав HTML-челендж, а вітрина намагалась прочитати його як список товарів. Мобільні додатки банків і доставки роблять те саме, лише з гіршим UX: одне речення без кнопки «показати деталі». У такій тиші людина звинувачує «інтернет», хоча кабель тут ні при чому.

Окремий зоопарк — чати з мовними моделями і агентами. Модель має повернути структурований JSON для виклику інструмента, але обриває рядок на ліміті токенів, обгортає його в блок markdown або вставляє «розумні» лапки всередині поля. Клієнт агента пише Failed to parse response і зупиняє сценарій. Те саме бачать користувачі Make, Zapier і внутрішніх ботів у Telegram, коли відповідь LLM не проходить модуль Parse JSON.

Касові й облікові системи в Україні теж не осторонь. У примітках до версії 2022.0.36 на сайті torgsoft.ua прямо описано виправлення: для банківських терміналів за протоколом JSON відповідь ламалась, якщо в назві торгової точки були подвійні лапки. Повідомлення було дослівним — «Не вдалося розпарсити відповідь JSON». Один символ у вивісці кав’ярні зупиняв оплату карткою. Такі історії добре показують, що помилка живе не лише в «хмарі», а й на стійці біля кавомашини.

Браузерні розширення, віджети аналітики, плагіни CMS і навіть валідатори XML Sitemap показують споріднені формулювання: «документи, які не вдалося розпарсити». Спільний знаменник простий. Десь є очікувана схема, десь є реальний потік байтів, і між ними — розрив. Чим далі сервіс від розробника, тим менш зрозумілим виглядає цей розрив для людини за екраном.

Як діагностувати збій, не гадаючи навмання

Почніть із сирого тіла, а не з емоцій. У браузері відкрийте інструменти розробника, вкладку Network, повторіть дію й знайдіть запит, який впав. Подивіться статус, заголовок Content-Type і Preview/Response. Якщо Content-Type каже text/html, а клієнт кличе response.json(), подальші танці з бубном зайві: парсити нічого, треба лікувати сервер або маршрут. Цей один погляд відсікає півгодини суперечок «у мене все працює, у тебе ні».

Порівняйте обіцяну довжину з фактичною. Заголовок Content-Length або розмір у Network покаже, чи відповідь обрізана. Обрізаний JSON майже завжди закінчується посеред рядка: немає закривної дужки, немає лапки. Повторіть запит із іншого каналу — Postman, curl, інший браузер, мобільний інтернет замість офісного Wi-Fi. Якщо «ззовні» все чисто, винен корпоративний проксі, антивірус-HTTPS-сканер або розширення.

Кодування перевіряйте окремо. Відкрийте відповідь у редакторі, який показує BOM і hex. Байти EF BB BF на старті — класичний BOM. Кракозябри замість українських літер — неправильна сторінка кодів. За моїм досвідом розбору інтеграцій із 1С та старими PHP-бекендами саме Windows-1251, який «раптом» проліз у JSON, давав найпідступніші збої: валідатор нібито «майже зелений», а клієнт на UTF-8 падав на першому прізвищі з апострофом.

Правило, яке відсікає години хаосу: спочатку прочитайте перший символ тіла відповіді. Дужка «{» або «[» — це претендент на JSON. Символ «<» — HTML. Літера «u» в тексті помилки — порожнеча. Літера «o» — ви парсите вже об’єкт. Ця абетка рятує швидше за будь-який форум.

Що перевірити	Норма	Ознака поломки	Куди копати далі
HTTP-статус	2xx для успіху	401, 403, 502, 503, 520	Авторизація, шлюз, апстрім
Content-Type	application/json	text/html, text/plain, порожньо	Маршрут API, nginx, WAF
Перший символ тіла	{ або [	<, порожньо, BOM	Заглушка, кодування, порожній handler
Повнота JSON	Закриті дужки, валідний розбір	Unexpected end of data	Таймаути, стрімінг, ліміт тіла
Локаль клієнта	Повторюється скрізь	Лише в одному браузері чи мережі	Кеш, розширення, SSL-інспекція

Після таблиці тримайте звичку зберігати request id, час і скрін Network. Без цих трьох речей підтримка сервісу крутитиме пальцем біля скроні, навіть якщо ви маєте рацію. У нашій практиці інцидент закривався в рази швидше, коли клієнт одразу прикладав сире тіло, а не лише переказ «у мене нічого не відкривається». Один збережений пакет відповіді дорожчий за десять емоційних повідомлень у чаті.

Шлях виправлення для користувача без коду

Оновіть сторінку жорстко, не зі звички «F5 навмання», а щоб скинути напівмертвий кеш. У більшості браузерів це Ctrl+F5 або Cmd+Shift+R. Потім вийдіть і зайдіть знову: протухла сесія часто підсовує HTML логіну під виглядом API. Якщо помилка сидить у мобільному додатку — повністю закрийте його в диспетчері, а не згортайте. «Завислий» сокет продовжує читати обрізаний потік і знову падає на parse.

Перевірте мережу як окремий персонаж драми. Корпоративний VPN, антивірус із перевіркою HTTPS, «прискорювачі» мобільного інтернету і публічний Wi-Fi в кафе люблять вставляти власні HTML-вставки. Вимкніть VPN, спробуйте мобільний канал, інший браузер без розширень. Розширення для блокування реклами інколи ріже відповіді аналітики й залишає клієнту уламки JSON. Якщо в інкогніто без VPN усе оживає, сервер уже не головний підозрюваний.

Оновіть програму до останньої стабільної збірки. Постачальники кас, ботів і «розумних» помічників регулярно латають парсери саме через такі кейси, як лапки в назві точки чи змінений формат відповіді термінала. Якщо оновлення немає, а бізнес стоїть — відкрийте ту саму дію з іншого пристрою. Коли «на телефоні колеги все ок», проблема локальна: кеш, час пристрою, проксі або стара версія WebView.

Не ігноруйте час. Короткочасні 503 на стороні хмари минають за хвилини, і повтор через 2–3 хвилини — нормальна тактика, а не забобон. Але якщо збій тримається годинами, пишіть у підтримку з фактами: точний текст помилки, час за Києвом, назва дії, скрін. Формулювання «нічого не працює» не лікує парсер. Формулювання «о 09:14 під час оплати карткою каса показала “Не вдалося розпарсити відповідь”, інші продажі готівкою йдуть» — уже діагноз наполовину.

Поради, які реально рятують час

Зробіть контрольну закупівлю в інкогніто. Режим інкогніто вимикає більшість розширень і окремий кеш. Якщо там усе відкривається, не звинувачуйте сервер: шукайте блокувальник, стару куку або зламане розширення перекладу, яке псує JSON на льоту.
Не тисніть «повторити» десять разів поспіль. Шквал повторів під час 503 перетворює короткочасний збій шлюзу на вал обрізаних відповідей. Зачекайте, оновіть один раз, запишіть час. Інакше логи підтримки виглядають як DDoS від однієї каси.
Перевірте «розумні» лапки в назвах. Якщо ви адмін магазину чи бота, приберіть з назви торгової точки, товару й акції символи « » ” ‘ . Саме вони найчастіше ламають JSON на терміналах і в шаблонах повідомлень.
Дивіться на годинник пристрою. Збита дата ламає TLS і підсовує проміжні помилки шлюзу. Парсер тоді чесно падає на HTML від антивірусу, який не довіряє сертифікату.
Зберігайте номер чека, id замовлення, request id. Без якоря ніхто не знайде ваш конкретний зламаний пакет серед тисяч успішних. Один ідентифікатор дорожчий за есей у чаті підтримки.

Ці поради звучать буденно, але саме буденність тут лікує. Користувач рідко «погано натискає». Набагато частіше середовище — мережа, кеш, стара збірка — підсовує парсеру не той текст. Приберіть середовище з рівняння, і половина «містичних» збоїв розсипається сама. Решта половина вже потребує логів і вендора, а не десятого перезавантаження.

Що робити розробнику, коли JSON «ламається»

Ніколи не парсьте тіло наосліп. Спочатку статус, потім Content-Type, потім довжина, потім parse у захищеному блоці. Якщо статус 5xx або тип text/html — поверніть зрозумілу доменну помилку «сервіс тимчасово віддав не JSON», а не сирий SyntaxError користувачу. Користувач не винен у граматиці RFC. Він винен лише в тому, що довірив вам кнопку, яка має говорити людською мовою.

Обгорніть розбір. У JavaScript це try/catch навколо JSON.parse або перевірка response.ok перед response.json(). У Python — json.JSONDecodeError. У Go — помилка json.Unmarshal. Логуйте перші 200–500 символів тіла, статус і заголовки, але не секрети. Порожній catch, який ковтає збій і малює «щось пішло не так», краде у вас години на проді.

Стрімінг обробляйте як стрімінг, а не як один великий рядок. SSE і chunked LLM-відповіді прилітають шматками: парсити незавершений об’єкт рано. Збирайте буфер до межі повідомлення, парсьте кадр, і лише кадр. Якщо модель має повернути інструментальний JSON — вимагайте structured output / schema, а не «будь ласка, відповідай JSON» у промпті. Промпт-ввічливість не замінює граматику.

Нормалізуйте кодування на межі системи. Віддавайте UTF-8 без BOM, ставте charset у заголовках, екрануйте лапки в назвах точок і товарів, забороніть типографські лапки на введенні. Валідуйте схему (JSON Schema, Zod, Pydantic) до того, як дані поїдуть у касу, бота чи білінг. Тести з фікстурами «зайва кома», «HTML 503», «порожнє тіло», «BOM», «ем dash у назві» коштують дешевше, ніж інцидент у п’ятницю ввечері.

Клієнт, який парсить усе підряд, — не «гнучкий». Він сліпий. Сліпий клієнт перетворює чужий інцидент шлюзу на ваш інцидент у продукті, і саме так народжується репутація «у них постійно щось не працює». Краще чесний банер «сервіс віддав нечитабельну відповідь», ніж порожній екран, який користувач списує на ваш бренд.

ШІ-чати, боти, касові системи та інші особливі випадки

Мовні моделі полюбляють бути красномовними там, де контракт вимагає сухого JSON. Вони додають пояснення перед дужкою, обгортають результат у трійні зворотні лапки, ставлять кому «для краси» або обривають глибоку вкладеність, коли закінчується вікно контексту. Агентна обгортка тоді пише Failed to parse response / Failed to parse tool call: Unexpected end of content. Ліки — schema, обмеження max tokens із запасом, повтор із жорсткішим інструктажем і відмова парсити markdown-обгортку без зняття огорожі.

Боти в месенджерах ловляться на інший гачок: проксі Telegram, довгі відповіді й таймаути webhook. Сервер бота вже закрив з’єднання, а апстрім дотягує HTML-сторінку помилки хостингу. Парсер команди бачить не payload callback, а nginx 504. Додайте ідемпотентність обробки оновлень і не вважайте кожен parse fail фатальним: інколи це просто повторюваний webhook із гнилим тілом.

Каси й банківські термінали — третій світ. Протокол JSON поверх TCP/COM чутливий до лапок, кодувань і «зайвих» полів прошивки. Історія з Торгсофт добре ілюструє механіку: подвійні лапки в назві торгової точки ламали розбір відповіді термінала, поки вендор не виправив екранування у версії 2022.0.36. Якщо ви керуєте мережею точок, тримайте назви простими, прошивки однаковими, а логи термінала — увімкненими. Кава може бути авторською, JSON — ні.

Міні-кейс із практики

У нашій практиці ми стикалися з таким випадком, коли невелика кав’ярня в години пік не могла закрити безготівкові чеки. Касир бачив «Не вдалося розпарсити відповідь», гість нервував, черга росла. Готівка проходила, інтернет «був», пін-пад блимав зеленим. Адмін перезавантажував касасофт тричі — без ефекту. У логах термінала лежав майже валідний JSON, але всередині поля merchantName красувалась назва з лапками-ялинками, скопійованими з Instagram-біо.

Ми замінили типографські лапки на звичайний дефіс у назві точки, оновили касову збірку з патчем екранування і додали правило валідації: заборонені символи ” ‘ < > у критичних полях. Наступного ранку безготівка пішла як по маслу. Жодної «магії мережі» не було. Був текст, який не вліз у граматику парсера, і люди, які цей текст вважали невинною прикрасою бренду.

Урок кейсу жорсткий і корисний. Дані з маркетингу, CRM і вивіски рано чи пізно доїдуть до протоколу, який не читає поезію. Якщо поле може потрапити в JSON, його треба чистити на вході, а не сподіватись, що «термінал якось прожує». Парсер не жує. Він або ковтає граматично правильний текст, або відмовляється працювати на очах у черги.

Як зробити обмін даними стійким до цієї помилки

Стійкість починається з контракту, а не з try/catch. Опишіть схему відповіді, версіонуйте API, не ламайте поля мовчки, віддавайте помилки тим самим JSON, що й успіх. HTML-сторінка 503 від nginx — зручна для людини в браузері і отруйна для клієнта каси. Для API-зон вимикайте підміну тіла на «гарну» HTML-заглушку. Нехай 503 лишається JSON з кодом і request id.

На клієнті зробіть три шари. Транспортний: повторювати 429/502/503/504 із експоненційним відступом і джитером, не чіпати 400/401/403/404. Синтаксичний: parse тільки після перевірок типу й статусу, з лімітом розміру. Доменний: схема, обов’язкові поля, типи. Коли шари змішані, «не вдалося розпарсити» маскує і даун стріму, і баг у вашому DTO, і протухлий токен. Розділені шари говорять різними словами — і це добре.

Спостерігайте за частотою parse-помилок як за окремою метрикою. Стрибок після деплою — ваша схема. Стрибок без деплою — чужий шлюз або CDN. Стрибок лише в одному регіоні — локальний проксі або кодування. Алерт «parse_fail_ratio понад 1% за 5 хвилин» цінніший за алерт «CPU 80%», бо користувач бачить саме parse fail, а не ваш процесор.

Поширені помилки, яких варто уникати

Парсити відповідь без перевірки статусу. Код 500 з HTML-тілом не стане об’єктом від того, що ви дуже хочете. Спочатку статус, потім тип, потім parse. Інакше кожен інцидент інфраструктури маскується під «баг фронту».
Викликати JSON.parse двічі «для надійності». Другий виклик отримує вже об’єкт, рушій кастує його до “[object Object]” і падає на token o. Надійність тут імітація, не захист.
Глушити SyntaxError порожнім catch. Користувач бачить тишу, ви втрачаєте тіло, інцидент живе тижнями. Логуйте прев’ю тіла. Тиша — ворог діагностики.
Вважати JavaScript-об’єкт і JSON одним і тим самим. Кома в кінці, одинарні лапки, коментарі, undefined — легальні в JS і заборонені в JSON. Копіпаста з консолі в файл фікстури — класичний шлях до збою на проді.
Зберігати конфіги як «UTF-8 with BOM», бо так зручніше в Блокноті. BOM на позиції 0 валить парсер. Зберігайте UTF-8 без BOM. Крапка.
Пускати сирі назви з CRM у протокол термінала. Лапки, бекслеші й емодзі в merchantName уже ламали живі каси. Санітизація полів — не перфекціонізм, а гігієна.
Просити модель «відповідати JSON» без схеми. Ввічливий промпт не є граматикою. Без structured output ви будете вічно знімати огорожі markdown і латати коми.

Кожна з цих помилок виглядає дрібницею, поки черга не стоїть біля каси. Код, який «ну майже завжди працює», — найдорожчий вид коду, бо він бреше в спокійні дні й вибухає в пікові. Виправляйте звичку, не лише рядок. Звичка парсити наосліп повертається навіть після одного вдалого хотфікса, якщо її не закріпити рев’ю й тестом.

Чек-лист для самоперевірки

Я відкрив сире тіло відповіді, а не лише текст помилки в UI.
Я зафіксував HTTP-статус, Content-Type, час і request id.
Перший символ тіла — { або [; якщо ні, я не намагаюсь «полагодити JSON», я лікую джерело HTML/порожнечі.
Тіло проходить валідатор JSON без «ручного прижмурювання ока».
Немає BOM, немає Windows-1251, українські літери читаються як літери.
Я не паршу undefined, порожній рядок і вже розібраний об’єкт.
Повтор з іншої мережі й іншого клієнта дав той самий або інший результат — і я це записав.
Назви точок, товари, повідомлення бота не містять сирих лапок і бекслешів.
Клієнт показує людині зрозумілу фразу, а в логи пише технічні деталі.
Є метрика parse_fail і алерт, а не лише скриншот у чаті команди.

Пройдіть список уголос, ніби це передпольотна перевірка. Якщо хоч один пункт «ну якось потім», саме він і вистрілить. Чек-лист дешевий. Повторний інцидент у п’ятницю — ні. Краще десять нудних галочок, ніж один публічний збій на касі в годину пік.

Запитання, які ставлять після першої появи збою

Чому сайт відкривається, а дані всередині — ні?

HTML оболонки і JSON даних їдуть різними маршрутами. Оболонка може віддатись із CDN ідеально, а запит /api/cart отримати 503 із HTML-заглушкою. Парсер картки падає, шапка сайту живе. Дивіться не на «чи вантажиться домен», а на конкретний XHR або fetch у Network.

Чи допоможе перевстановлення програми?

Інколи так, якщо зламаний локальний кеш або стара збірка парсера. Інколи ні, якщо сервер як і раніше віддає HTML замість JSON. Перевстановлення без перевірки тіла відповіді — лотерея. Зробіть її після діагностики, не замість неї.

Це вірус, злам чи «мене заблокували»?

Майже ніколи. Формулювання про парсинг означає зламану структуру тексту, а не вирок службі безпеки. Виняток — WAF, який підсунув HTML-челендж замість API: вигляд як «блок», механіка як «не той Content-Type». Перевірка з іншої мережі розводить ці сюжети за хвилину.

Чому в Postman все добре, а в додатку — ні?

Різні заголовки, різна авторизація, інший Accept, інший таймаут, інколи навіть інший базовий URL. Додаток може ходити через шлюз, який Postman обходить. Порівняйте запит, згенерований із Postman, із реальним запитом клієнта: хост, шлях, заголовки, тіло. Розбіжність в одному заголовку Authorization уже достатня, щоб замість JSON приїхала сторінка логіну.

ШІ-чат знову пише про parse. Це модель «дурна»?

Модель не дурна — вона ймовірнісна. Вона не підписувала контракт RFC 8259. Без схеми й перевірки на клієнті будь-яка модель рано чи пізно віддасть зайву кому або обірве дужку. Лайте інструментальний шар, а не «коефіцієнт інтелекту».

Скільки разів повторювати запит?

Для 429, 502, 503 і 504 — два-три рази з паузою, що росте. Для 400 і «тіло не JSON при 200» повтори не лікують граматику: треба фіксити payload або сервер. Сліпий цикл повторів лише маскує діру й битиме ліміти каси чи API-ключа. Краще один осмислений повтор, ніж десять панічних.

Ключові інсайти

«Не вдалося розпарсити відповідь» означає одне: клієнт не зміг прочитати структуру отриманого тексту. Це не вирок мережі й не обов’язково баг кнопки, на яку ви натиснули.
Перший символ тіла каже правду швидше за будь-який форум: { або [ — JSON-кандидат, < — HTML, порожнеча — немає чого парсити.
JSON суворіший за JavaScript. Зайва кома, одинарні лапки, BOM і «гарні» лапки з маркетингу валять прод так само впевнено, як падіння бази.
Для людини без коду працює короткий шлях: інкогніто, інша мережа, оновлення, пауза на 503, лист у підтримку з часом і сирим текстом помилки.
Для розробника працює шарність: статус і тип, захищений parse, схема, метрика parse_fail, заборона HTML-заглушок на API-маршрутах.
Найдорожчі збої народжуються на стику світів: назва кав’ярні з Instagram, відповідь термінала, стрім моделі, проксі кафе. Чисті поля й контракт дешевші за вибачення перед чергою.

Парсер — прискіпливий читач без почуття гумору. Він не «інколи прощає»: або приймає граматику, або зупиняє сценарій на очах у користувача. Поважайте цю прискіпливість: віддавайте чистий UTF-8 JSON, перевіряйте, що саме приїхало, і не маскуйте чужі HTML-заглушки під свої об’єкти. Тоді фраза «Не вдалося розпарсити відповідь» залишиться рідкісним експонатом у логах, а не ритуалом кожної ранкової зміни.

Кількість переглядів: 5