Публикация через JSON: что проверить между входящим файлом и страницей

Что осталось от архивного описания

Старый материал называет каталог api/inbox/ и скрипт api/publish.py. В нём перечислены обработка входящих файлов с параметром --process-inbox и чтение стандартного ввода с параметром --from-stdin. Здесь это исторические сведения из локального снимка, а не проверенные команды действующей системы.

Упоминание webhook в исходнике условное: он предлагался при добавлении оболочки Flask или FastAPI. Поэтому нельзя представлять сетевой интерфейс как уже установленную функцию. Для его использования сначала понадобятся отдельная реализация, проверка доступа и тестирование.

Архивный контракт требует slug, title и content; description, keywords и ogImage описаны как необязательные. Поле content тогда содержало HTML. При проектировании нового приёмника эти значения стоит явно версионировать, чтобы старый пакет не трактовался по новым правилам молча.

Проверка начинается до рендеринга

Принимайте только объект ожидаемой версии. Для обязательных полей проверьте тип, непустое значение и ограничения размера. Не используйте slug как произвольный путь к файлу. Преобразование идентификатора в адрес должно происходить внутри контролируемого каталога.

• Проверьте конфликт адреса с уже существующей публикацией и выберите явный режим: создание или обновление.
• Не заменяйте дату первой публикации временем повторной доставки пакета.
• Для обложки различайте отсутствующее поле, намеренное отсутствие изображения и недоступный файл.
• Не допускайте скрипты и обработчики событий в переданном содержимом; безопаснее принимать ограниченное семантическое дерево.

Метаданные требуют проверки смысла: заголовок должен соответствовать тексту, описание не должно обещать того, чего в статье нет. Языковая модель может предложить формулировки, но не подтверждает достоверность новости или право использовать чужое изображение.

Сохраняйте состояния обработки

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

Повтор одного пакета не должен создавать вторую страницу. Храните идентичность запроса и результат предыдущей обработки. Если текст изменился, оформите новую версию с явным намерением обновить статью, сохранив историю и прежний публичный адрес.

Прочитайте именно выпущенный результат

Черновой HTML откройте отдельно от публичного блога. Проверьте основной текст, канонический адрес, дату, ссылки и состояние индексации. Если обложки нет, страница должна корректно обходиться без неё, а не получать случайную картинку ради прохождения проверки.

После разрешённого выпуска прочитайте точный адрес страницы и связанные записи индекса. Убедитесь, что заголовок и версия совпадают с согласованным пакетом. Код завершения обработчика не доказывает, что нужная страница доступна читателю или попала в навигацию.

Для проверки восстановления смоделируйте остановку между сохранением HTML и обновлением индекса. Повторный запуск должен завершать недостающий этап, не менять дату и не дублировать запись. До такого испытания описание автоматической публикации остаётся проектом, даже если одиночный пример успешно отрендерился.