Веригите от пренасочвания чупят scrapers. Бинарните отговори се повреждат, когато се декодират като текст. Два проблема, които възникват постоянно, след като преминете етапа „изтегли страница, парсни HTML“.
Пуснахме две нови опции за request, за да се справим и с двете: followRedirects и returnBuffer. Те вече са активни в API.
Как работи
Контрол на пренасочванията с followRedirects
Повечето scraping APIs обработват пренасочванията като булева стойност: следвай ги или не. Това работи, докато не попаднете на верига от пренасочвания, която се зацикля, или докато не ви потрябва самият междинен 302 response, за да извлечете проследяващ параметър.
followRedirects на FourA приема цяло число между 0 и 20. Пропуснете го (или задайте 0) и ще получите обратно суровия redirect response, заедно с всички headers. Задайте го на 5 и request ще последва до пет стъпки, преди да върне това, на което се приземи.
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
}'
Това следва до три пренасочвания. Ако веригата се разреши в рамките на две, получавате финалната страница. Ако е по-дълга от три, получавате това, което е върнала третата стъпка.
Разликата е по-важна, отколкото си мислите. Сайтовете за електронна търговия пренасочват през проследяващи URLs, преди да се приземят на продуктовата страница. Вие искате да ги последвате. Но афилиейт мрежите и услугите за съкращаване на URLs понякога създават вериги с дълбочина от шест, седем, осем стъпки. А някои цикли от пренасочвания никога не се разрешават. Ограничаването до конкретно число означава, че събирате данни, без да засядате в безкраен цикъл, който изразходва вашия request timeout.
Преди това заобиколният начин беше изпращане на request с деактивирани пренасочвания, ръчно парсване на Location header и изпращане на нов request. Това са минимум две API повиквания, двойно по-голяма латентност и код, който трябва да поддържате. Сега е едно повикване с число.
Сурови бинарни отговори с returnBuffer
Когато събирате изображения, PDFs или protobuf payloads, текстовото декодиране унищожава данните. HTTP библиотеката приема, че response е текст, прилага откриване на charset и тихо поврежда всеки байт, който не съвпада. Protobuf става нечетим. Изображенията чупят своите headers. Накрая получавате повредени файлове и никакво ясно съобщение за грешка, което да обясни защо.
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
}'
Response body се връща като сурови байтове (base64-кодирани в JSON отговорите). Декодирайте го от ваша страна и ще имате точно това, което сървърът е изпратил. Без предположения за charset, без конвертиране на кодирането, без тихо повреждане.
Това беше един от най-често срещаните тикети за поддръжка, които виждахме: потребители, събиращи продуктови изображения или PDF каталози, получават файлове, които не се отварят. Решението винаги беше едно и също, но сега има флаг за това, вместо заобиколен начин.
Ефект
И двете функции намаляват броя на API повикванията за задача. followRedirects елиминира ръчните цикли за преследване на пренасочвания. returnBuffer елиминира цикъла „изтегли, осъзнай, че е повреден, изтегли отново с различни настройки“.
За цели с множество пренасочвания (афилиейт линкове, URL shorteners, проследяващи вериги за електронна търговия), видяхме спад в броя на requests с 40-60% при ранните тестове, когато потребителите преминават от ръчно управление на пренасочванията към followRedirects. А за задачи за събиране на бинарни данни (продуктови изображения, изтегляне на документи), returnBuffer превръща заобиколния метод от няколко стъпки в една единствена опция (ранни резултати).
Това не са лъскави функции. Те са от типа неща, за които не мислите, докато вашият scraper не се счупи в 3 сутринта, защото даден сайт е добавил допълнителна стъпка на пренасочване към своя checkout flow.
За напреднали потребители
Комбинирайте followRedirects с валидиране на response за прецизен контрол над веригите от пренасочвания. Следвайте пренасочванията, но прекратете request с грешка, ако крайната дестинация удари на камък:
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"] }
}
}'
Това следва до пет пренасочвания, след което проверява финалния response. Ако сайтът ви е пренасочил към CAPTCHA страница или екран за отказан достъп, request се проваля чисто. Без излишни данни за филтриране по веригата надолу.
За събиране на бинарни данни, комбинирайте returnBuffer с HEAD requests, когато трябва да проверите типовете съдържание преди изтегляне на големи файлове. FourA обработва HEAD правилно (предотвратявайки често срещани грешки в libcurl вътрешно), така че можете да инспектирате headers, без да изтегляте body. Проверете Content-Type, решете дали си струва изтеглянето и след това направете пълния request с returnBuffer: true.
И ако използвате браузърни задачи за цели с тежък JavaScript, имайте предвид, че тези опции се прилагат за директния HTTP engine. Browser requests обработват пренасочванията чрез вградената навигация на Chrome, която ги следва по подразбиране без ограничение.
Какво предстои
Работим по предоставянето на повече контроли на ниво request през API: персонализирана DNS резолюция, настройка на timeout за всяка фаза и опции за обработка на сертификати. Целта е пълната мощ на curl-impersonate чрез чист REST интерфейс, без инфраструктурни разходи.
Ако има конкретна опция, от която се нуждаете, ние ви слушаме. Дашбордът вече показва как се справят вашите requests с тези нови опции, така че можете сами да измерите разликата.