инженер-локальный-http-microservice

Каждая царапина становится локальным микросервисом Большинство инструментов очистки заканчиваются фразой «вот ваш JSON в терминале». Scrapwright заканчивается словами «вот ваша конечная точка». Каждый создаваемый вами парсер становится именованным HTTP-сервисом на локальном хосте с моделью заданий, очередями, проверками работоспособности и даже CRUD на уровне шагов для CI. Это экскурсия по этой поверхности, потому что дизайн API — это половина продукта. Схема двух звонков Развернутые службы находятся по адресу http://localhost:8765/api/v1 (порт и ключ API настраиваются; заголовок X-API-Key для всего, кроме /health): # Отправить — немедленно возвращается с идентификатором задания JOB_ID=$(curl -s -X POST http://localhost:8765/api/v1/services/my-service/execute \ -H "X-API-Key: dev-key" -H "Content-Type: application/json" \ -d '{"input": {"query": "беспроводная мышь"}}' | jq -r '.jobId') # Подождать — блокируется до завершения (таймаут до 300с) curl -s "http://localhost:8765/api/v1/jobs/$JOB_ID/wait?timeout=120" \ -H «X-API-Ключ: ключ разработчика» | jq '.job.result' Разделение выполнение/ожидание — это правильный асинхронный контракт: отправки дешевы, результаты основаны на извлечении (/jobs/{id} для неблокирующего статуса), и оба одинаково хорошо подходят для заданий cron, конвейеров CI и обработчиков сервера. Ответ представляет собой контракт, а не большой двоичный объект.