Веригите от пренасочвания чупят скраперите. Двоичните отговори се повреждат при декодиране като текст. Два проблема, които възникват постоянно, след като преминете етапа "извличане на страница, парсване на HTML".
Пуснахме две нови опции за заявки, за да се справим и с двете: followRedirects и returnBuffer. Вече са налични в API.
Как работи
Контрол на пренасочванията с followRedirects
Повечето API за скрапване третират пренасочванията като булева стойност: следвай ги или не. Това работи, докато не срещнете зациклена верига от пренасочвания или докато не ви потрябва самият междинен 302 отговор, за да извлечете проследяващ параметър.
followRedirects на FourA приема цяло число между 0 и 20. Пропуснете го (или задайте 0) и получавате обратно суровия отговор за пренасочване, заедно с хедърите. Задайте стойност 5 и заявката ще следва до пет пренасочвания, преди да върне крайния резултат.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/short-link",
"followRedirects": 3,
"unblocker": true
}'
Това следва до три пренасочвания. Ако веригата приключи в две, получавате крайната страница. Ако е по-дълга от три, получавате това, което е върнал третият хоп.
Разликата е по-важна, отколкото изглежда. Сайтовете за електронна търговия пренасочват през проследяващи URL адреси, преди да стигнат до продуктовата страница. Искате да ги следвате. Но афилиейт мрежите и съкращаващите URL услуги понякога създават вериги от шест, седем, осем стъпки. А някои цикли от пренасочвания не завършват никога. Ограничаването до конкретен брой означава, че събирате данни, без да засядате в безкраен цикъл, който изчерпва вашия request timeout.
Преди това заобиколното решение беше изпращане на request с изключени пренасочвания, ръчно парсване на Location header и изпращане на нов request. Това са минимум две API повиквания, двойно по-голяма латентност и код, който трябва да поддържате. Сега е едно повикване с число.
Необработени бинарни отговори с returnBuffer
Когато събирате изображения, PDF файлове или protobuf пакети, декодирането на текст поврежда данните. HTTP библиотеката приема, че отговорът е текст, прилага разпознаване на кодировката и тихо разваля всеки байт, който не съвпада. Protobuf става нечетим. Headers на изображенията се повреждат. Накрая получавате повредени файлове без ясно съобщение за грешка, което да обясни причината.
returnBuffer указва на API да пропусне напълно текстовото декодиране.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product-image.jpg",
"returnBuffer": true
}'
Тялото на response се връща като сурови байтове (base64 кодирани в JSON responses). Декодирайте го от ваша страна и получавате точно това, което сървърът е изпратил. Без предположения за charset, без конвертиране на кодирането, без тихо повреждане на данните.
Това беше един от по-честите проблеми в поддръжката: потребители събират продуктови изображения или PDF каталози и получават файлове, които не се отварят. Решението винаги беше едно и също, но сега има флаг за това вместо заобиколен метод.
Ефект
И двете функционалности намаляват броя API извиквания за задача. followRedirects елиминира циклите за ръчно проследяване на пренасочвания. returnBuffer елиминира цикъла "изтегли, разбери, че е повредено, изтегли отново с различни настройки".
За цели с много пренасочвания (афилиейт линкове, съкращаване на URL адреси, тракинг вериги в електронната търговия) наблюдаваме спад на заявките с 40-60% при ранни тестове, когато потребителите преминат от ръчна обработка към followRedirects. А за задачи със събиране на бинарни данни (продуктови изображения, сваляне на документи), returnBuffer превръща многостъпковия заобиколен метод в единична опция (ранни резултати).
Това не са крещящи функционалности. Те са от типа неща, за които не се замисляте, докато вашият scraper не спре в 3 сутринта, защото сайтът е добавил допълнителна стъпка на пренасочване към процеса на плащане.
За напреднали потребители
Комбинирайте followRedirects с валидация на response за прецизен контрол върху веригите от пренасочвания. Следвайте пренасочванията, но маркирайте request като неуспешен, ако крайната дестинация срещне проблем:
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "X-API-Key: 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"] }
}
}'
Това следва до пет пренасочвания, след което проверява крайния response. Ако сайтът ви пренасочи към страница за верификация или екран за отказан достъп, заявката се проваля чисто. Без излишни данни, които да филтрирате впоследствие.
При събиране на бинарни данни комбинирайте returnBuffer с HEAD заявки, когато трябва да проверите типа съдържание преди изтегляне на големи файлове. FourA обработва HEAD правилно, така че можете да инспектирате headers, без да изтегляте тялото. Проверете Content-Type, преценете дали си струва изтеглянето и след това направете пълната заявка с returnBuffer: true.
А ако използвате browser tasks за цели с тежък JavaScript, имайте предвид, че тези опции се отнасят за директния HTTP engine. Browser заявките обработват пренасочванията чрез вградената навигация на браузъра, която ги следва по подразбиране без лимит.
Какво предстои
Работим по предоставянето на повече контроли на ниво заявка през API: персонализирана DNS резолюция, настройка на timeout за отделните фази и опции за обработка на сертификати. Целта е пълен контрол върху профила на браузъра през изчистен REST интерфейс, без излишни разходи за инфраструктура.
Ако имате нужда от конкретна опция, ще се радваме на обратна връзка. В dashboard вече се вижда как се представят вашите заявки с тези нови опции, така че можете сами да измерите разликата.