Веригите от пренасочвания чупят скрейперите. Двоичните отговори се повреждат, когато се декодират като текст. Два проблема, които възникват постоянно, щом преминете етапа "изтегляне на страница, парсване на HTML".
Внедрихме две нови опции за заявки за справяне и с двете: followRedirects и returnBuffer. Те вече са активни в API-то.
Как работи
Контрол на пренасочванията с followRedirects
Повечето скрейпинг API-та обработват пренасочванията като булеви стойности: следват ги или не. Това работи, докато не попаднете на зациклена верига от пренасочвания или не ви потрябва самият междинен 302 отговор за извличане на проследяващ параметър.
followRedirects на FourA приема цяло число между 0 и 20. Пропуснете го (или задайте 0) и ще получите суровия отговор от пренасочването с всички хедъри. Задайте го на 5 и заявката ще проследи до пет скока, преди да върне крайния резултат.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/short-link",
"followRedirects": 3,
"unblocker": true
}'
Това проследява до три пренасочвания. Ако веригата приключи в две, получавате крайната страница. Ако е по-дълга от три, получавате това, което е върнал третият скок.
Разликата има по-голямо значение, отколкото си мислите. Сайтовете за електронна търговия пренасочват през проследяващи URL адреси, преди да стигнат до продуктовата страница. Искате да ги проследите. Но партньорските мрежи и услугите за съкращаване на URL адреси понякога създават вериги с дълбочина шест, седем или осем скока. А някои цикли на пренасочване никога не приключват. Ограничаването до определен брой означава, че събирате данни, без да засядате в безкраен цикъл, който изчерпва таймаута на заявката ви.
Преди това заобиколното решение беше изпращане на заявка с изключени пренасочвания, ръчно парсване на Location хедъра и изпращане на друга заявка. Това са минимум две извиквания на API-то, двойно по-голяма латентност и код, който трябва да поддържате. Сега е едно извикване с число.
Сурови двоични отговори с returnBuffer
Когато събирате изображения, PDF файлове или protobuf данни, текстовото декодиране унищожава данните. HTTP библиотеката приема, че отговорът е текст, прилага разпознаване на charset и тихо поврежда всеки байт, който не съвпада. Protobuf става нечетим. Хедърите на изображенията се чупят. В крайна сметка получавате повредени файлове без очевидно съобщение за грешка, което да обясни защо.
returnBuffer казва на API-то да пропусне изцяло текстовото декодиране.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product-image.jpg",
"returnBuffer": true
}'
Тялото на отговора се връща като сурови байтове (base64 кодирани в JSON отговорите). Декодирайте го от ваша страна и имате точно това, което сървърът е изпратил. Без предположения за charset, без конвертиране на кодирането, без тихо повреждане.
Това беше един от най-честите тикети за поддръжка, които виждахме: потребители събират продуктови изображения или PDF каталози и получават файлове, които не се отварят. Решението винаги беше едно и също, но сега има флаг за него вместо заобикаляне на проблема.
Въздействие
И двете функции намаляват броя на извикванията на API-то за дадена задача. followRedirects елиминира ръчните цикли за проследяване на пренасочвания. returnBuffer елиминира цикъла "изтегляне, осъзнаване, че е повредено, повторно изтегляне с различни настройки".
За цели с много пренасочвания (афилиейт връзки, услуги за съкращаване на URL адреси, проследяващи вериги в електронната търговия) забелязахме спад в броя на заявките с 40 до 60 процента в ранните тестове, когато потребителите преминават от ръчна обработка на пренасочванията към followRedirects. А за задачи по събиране на двоични данни (продуктови изображения, изтегляне на документи), returnBuffer превръща многостъпковото заобиколно решение в една единствена опция (ранни резултати).
Това не са лъскави функции. Те са от нещата, за които не се замисляте, докато скрейперът ви не се счупи в 3 часа сутринта, защото някой сайт е добавил допълнителен скок за пренасочване към процеса на плащане.
За напреднали потребители
Комбинирайте followRedirects с валидиране на отговора за прецизен контрол върху веригите от пренасочвания. Следвайте пренасочванията, но провалете заявката, ако крайната дестинация удари на камък:
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product/12345",
"followRedirects": 5,
"unblocker": true,
"validate": {
"status": { "fail": [403, 503] },
"data": { "fail": ["Access Denied", "captcha"] }
}
}'
Това проследява до пет пренасочвания, след което проверява крайния отговор. Ако сайтът ви е пренасочил към CAPTCHA страница или екран с отказан достъп, заявката се проваля чисто. Без боклукчиви данни за филтриране по веригата.
За събиране на двоични данни съчетайте returnBuffer с HEAD заявки, когато трябва да проверите типовете съдържание, преди да изтеглите големи файлове. FourA обработва HEAD правилно, така че можете да проверявате хедърите, без да изтегляте тялото. Проверете Content-Type, решете дали си струва изтеглянето, след което направете пълната заявка с returnBuffer: true.
И ако използвате задачи в браузъра за цели, наситени с JavaScript, имайте предвид, че тези опции се прилагат към директния HTTP двигател. Заявките от браузъра обработват пренасочванията чрез вградената навигация на браузъра, която ги следва по подразбиране без ограничение.
Какво следва
Работим върху предоставянето на повече контроли на ниво заявка чрез API-то: персонализирано DNS разрешаване, настройка на таймаута за всяка фаза и опции за обработка на сертификати. Целта е пълна мощност за отблокиране чрез изчистен REST интерфейс, без инфраструктурна тежест.
Ако има конкретна опция, от която се нуждаете, ние слушаме. В таблото за управление вече се показва как се представят заявките ви с тези нови опции, така че можете сами да измерите разликата.