Парсинг сайтов — удалённая работа в Москве

Спарсить: посты, комментарии, профили. 1. Цель Разработать сервис, который по HTTP-запросу возвращает структурированные данные из LinkedIn (посты, комментарии, профили) в формате JSON. Сервис должен скрывать всю механику сбора данных за простым API: на вход — ссылка или параметры поиска, на выход — готовый JSON. 2. Общее описание - Сервис предоставляет REST HTTP API. - Авторизация клиентов — по API-ключу в заголовке (X-API-Key или аналог, зафиксировать в контракте). - Все ответы — JSON в кодировке UTF-8. - Формат ошибок единый: HTTP-код >= 400 и/или тело с полем error (текст причины). - Базовый URL сервиса — конфигурируемый. 3. Область работ (эндпоинты по приоритету) ?????????????????????????????????????????????????????????????????????????????????? ? Приоритет ? Эндпоинт ? Назначение ? ?????????????????????????????????????????????????????????????????????????????????? ? P0 ? GET /linkedin/post-comments ? комментарии под постом ? ?????????????????????????????????????????????????????????????????????????????????? ? P0 ? GET /linkedin/post ? один пост по ссылке ? ?????????????????????????????????????????????????????????????????????????????????? ? P1 ? GET /linkedin/profile ? профиль по ссылке ? ?????????????????????????????????????????????????????????????????????????????????? ? P1 ? GET /linkedin/profile-posts ? посты профиля ? ?????????????????????????????????????????????????????????????????????????????????? ? P2 ? GET /linkedin/profile-comments ? комментарии, оставленные профилем ? ?????????????????????????????????????????????????????????????????????????????????? ? P2 ? GET /linkedin/profile-search ? поиск профилей ? ?????????????????????????????????????????????????????????????????????????????????? Ядро — комментарии и посты (P0). При ограниченном бюджете первый этап: post-comments + post. 4. Функциональные требования 4.1 GET /linkedin/post-comments (P0) Параметры: post (URL поста, обязательный), sort_by (date|relevance, дефолт date), page (int, дефолт 1), pagination_token (опц.). Ответ: объект с массивом комментариев и токеном следующей страницы: { “items“: [ { “id“: “urn:li:comment:(activity:7300...,123456)“, “text“: “текст комментария“, “created_at“: “2026-07-10T14:32:00Z“, “reactions“: 4, “replies_count“: 2, “author“: { “name“: “Имя Фамилия“, “headline“: “Head of Growth“, “company“: “Acme“, “profile_url“: “https://www.linkedin.com/in/slug“, “avatar_url“: “https://...“, “linkedin_id“: “ACoAAB...“ }, “replies“: [ { “...“: “тот же объект комментария“ } ] } ], “next_pagination_token“: “...“ } Обязательные поля комментария: id, text, created_at, author.name, author.profile_url. Требование к id: стабильный и уникальный между запросами (предпочтительно нативный urn:li:comment:...). Один и тот же комментарий при повторном запросе обязан отдавать тот же id — от этого зависит дедупликация на стороне заказчика. 4.2 GET /linkedin/post (P0) Параметры: url (обязательный). Ответ: { “id“: “urn:li:activity:7300000000000000000“, “url“: “https://www.linkedin.com/feed/update/urn:li:activity:7300...“, “urn“: “urn:li:activity:7300000000000000000“, “text“: “полный текст поста“, “created_at“: “2026-07-09T08:00:00Z“, “author“: { “...“: “как в 4.1“ }, “metrics“: { “reactions“: 120, “comments“: 15, “reposts“: 6, “impressions“: 5400 }, “is_repost“: false, “repost_of_url“: null } Обязательные: id/urn, url, text, author, created_at. Метрики — желательно. Поддержать распознавание типов URN: activity, ugcPost, share. 4.3 GET /linkedin/profile (P1) Параметры: url (обязательный). Ответ: { “id“: “ACoAAB...“, “profile_url“: “https://www.linkedin.com/in/slug“, “name“: “Имя Фамилия“, “headline“: “CEO at Acme“, “company“: “Acme“, “location“: “Berlin, Germany“, “avatar_url“: “https://...“, “current_position“: { “title“: “CEO“, “company“: “Acme“ } } Обязательные: profile_url, name. 4.4 GET /linkedin/profile-posts (P1) Параметры: profile (URL), page, posted_limit (сколько последних постов), pagination_token. Ответ: массив постов формата 4.2 + next_pagination_token. 4.5 GET /linkedin/profile-comments (P2) Параметры: profile (URL), page, posted_limit, pagination_token. Ответ: массив комментариев формата 4.1 (с указанием, под каким постом оставлен: post_url). 4.6 GET /linkedin/profile-search (P2) Параметры: search (строка), title, company, location, page. Ответ: массив профилей формата 4.3 + пагинация. 5. Нефункциональные требования - Пагинация: через page и/или pagination_token; сервис возвращает токен следующей страницы. - Производительность: p95 ответа ? 10 с для комментариев одного поста; поддержка параллельных запросов. - Масштаб: заявить лимит RPS и месячный объём запросов. - Надёжность: корректные HTTP-коды; при недоступности источника — явная ошибка (503/error), не «пустой успех». - Устойчивость к блокировкам: ротация резидентных прокси, пул авторизованных сессий/аккаунтов, троттлинг, ретраи, обход rate-limit LinkedIn. - Свежесть: комментарии — актуальные; если есть кэш, указать TTL. - Наблюдаемость: логирование запросов, метрики успех/ошибка/латентность, алерты на рост банов. - Безопасность: ключи клиентов, лимиты по ключу, отсутствие хранения лишних персональных данных. 6. Критерии приёмки 1. Golden-набор: 20–30 эталонных ссылок (посты с комментариями и вложенными ответами, репосты, разные языки, профили) — 100% извлечение обязательных полей. 2. Стабильность ID: повторный запрос того же поста ? идентичные id комментариев. 3. Полнота: для поста с N комментариями возвращаются все N (с учётом пагинации), включая вложенные ответы. 4. Нагрузочный тест: заявленный RPS держится без деградации и роста ошибок. 5. Корректная обработка ошибок: недоступный/приватный/удалённый пост ? понятный код и сообщение, а не пустой успех. 7. Два пути реализации A. Собственная разработка - Плюсы: полный контроль, отсутствие платы за запрос, независимость. - Минусы: LinkedIn активно противодействует скраперам ? это постоянный проект поддержки (прокси, аккаунты, реакция на изменения LinkedIn); юридические риски (нарушение ToS LinkedIn). - Что заложить в бюджет: инфраструктура прокси, аренда/фарм аккаунтов, очередь задач, мониторинг банов, регулярный ремонт парсеров. B. Подрядчик / готовый провайдер - Критерии выбора: покрытие эндпоинтов из §3, стабильность ID комментариев, лимиты RPS и цена за 1000 запросов, SLA/uptime, задержка, юридическая модель получения данных, готовность отдавать формат из §4 (или предоставить адаптер).