Почему очевидный адрес может не работать
Когда собирал источники для новостного бота, несколько привычных адресов RSS оказались недоступными или возвращали обычную страницу. Сайты меняются: результат одного обследования нельзя считать постоянным фактом. Проверять наличие ленты нужно заново перед подключением.
Здесь разберу сам подход к проверке источника. Он полезен для RSS, Atom, внешнего API и любого сервиса, от которого зависит автоматизация.
Что нужно проверить в ответе
- HTTP-статус и конечный адрес после перенаправлений.
- Тип содержимого и фактический формат тела ответа.
- Наличие публикаций, заголовков и ссылок.
- Даты: есть ли они, читаются ли и относятся ли к публикации.
- Свежесть ленты и повторяемость ответа.
HTTP 200 означает, что сервер ответил, но не доказывает пригодность данных. Вместо ленты можно получить страницу входа, заглушку или сообщение об ограничении доступа.
Почему важна рабочая среда
Источник, доступный из браузера разработчика, может быть недоступен серверу. Влияют ограничения сети, частота запросов и требования площадки. Поэтому проверку повторяют из среды, где будет работать сборщик, не обходя правила доступа.
Ошибку нужно отличать от отсутствия источника. Тайм-аут, временный отказ и ограничение частоты не равны доказанному отсутствию ленты. Система должна показывать это различие, иначе список источников будет разрушаться при каждом временном сбое.
Как поддерживать каталог
Для каждого источника полезно хранить дату проверки, формат и замеченные ограничения. Неработающий источник требует видимого статуса и решения: повторить проверку, заменить или отключить. Молчаливое исчезновение новостей трудно заметить по одному выпуску.
При заказе парсера или сборщика данных начнём с разрешённых источников, частоты обновления и критериев полноты. Такой замер дешевле разработки системы вокруг непроверенной ленты.
