Резултати от заявки
Всяка request до FourA API се класифицира в точно един резултат. Резултатът се изчислява веднъж в момента на request и се записва към вашия API key. Вашият dashboard, activity feed и таксуване четат едно и също поле.
Само success се таксува.
Седемте резултата
| Резултат | Слой | Какво означава |
|---|---|---|
success |
n/a | Доставен е валиден response. Отчита се към вашата таксуема квота. |
application_error |
target | Целта върна HTTP 200, но тялото съдържаше поле за грешка. |
application_fail |
target | Целта върна код, различен от 2xx, който вашите правила за validate не приеха, или изобщо не върна response. |
client_error |
caller | Вашата request беше отхвърлена, преди да напусне FourA. Невалидни параметри, неправилно форматирана стойност за proxy, защитен от SSRF URL. |
rate_limit |
FourA | Вашият RPM или concurrency cap беше достигнат. |
service_error |
FourA | Бекендът върна 5xx или неговото тяло не беше валиден JSON. |
service_fail |
FourA | Мрежова грешка: timeout, отказана връзка, DNS грешка, прекъсване на връзката от страна на клиента. |
Колоната за слой ви показва кой е отговорен:
- target резултатите се отнасят за сайта, който сте извикали. Вашата request е достигнала успешно до FourA, а FourA е достигнал успешно до целта. Самата цел е върнала грешка.
- caller резултатите означават, че вашата request изобщо не е имала шанс. Коригирайте структурата на request.
- FourA резултатите са наша отговорност. Опитайте отново и проверете страницата за статус, ако те продължат.
Целеви сайт, който връща 403, е application_fail, а не client_error. Вашето извикване беше правилно форматирано. Сайтът просто отказа достъп.
Success зависи от validate
Без validate, API маркира дадена request като success само когато целта върне HTTP 200.
С validate, success следва правилата, които сте декларирали. Ако укажете на API, че 200 и 403 са приемливи за дадена request, 403 се връща като success. Тялото все още достига до вас непроменено.
curl -X POST https://eu.api.foura.ai/api/single/ \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"method": "GET",
"url": "https://target.example/feed",
"validate": {
"status": { "accept": [200, 403] }
}
}'
При това извикване, response с код 403 се зачита за success и се таксува като една request. Response с код 500 се зачита за application_fail и не се таксува.
Същата логика важи и за validate.headers и validate.data. Всеки response, който енджинът приеме спрямо вашите правила, се връща като success независимо от HTTP статуса.
Отражение върху таксуването
| Резултат | Таксуем | Отчита се към квотата |
|---|---|---|
success |
Да | Да |
application_error |
Не | Не |
application_fail |
Не | Не |
client_error |
Не | Не |
rate_limit |
Не | Не |
service_error |
Не | Не |
service_fail |
Не | Не |
Таксуват се само requests, които са доставили данните, които сте поискали. Неуспешните опити от страна на FourA, от страна на целта или от ваша страна са напълно безплатни.
Преглед на резултатите в Dashboard
Всяка request, направена от вашия API key, се показва във фийда Activity с нейния етикет за резултат. Страниците Metrics и Overview агрегират същото поле за кръгови диаграми и времеви линии.
Когато филтрирате Activity по резултат, можете също така да се фокусирате върху конкретен продукт (Single, Proxy, Browser), за да видите дали даден клас грешка е специфичен за един endpoint.
Евристики за повторен опит (Retry)
Първоначална политика за повторен опит, базирана на резултатите:
| Резултат | Безопасен ли е повторен опит? | Кога |
|---|---|---|
success |
n/a | Вече имате съответния response. |
application_error |
Понякога | Прочетете тялото за грешка на целта. Някои са временни, повечето не са. |
application_fail |
Понякога | Ако целта ви налага rate limit, намалете темпото. Ако ви блокира, преминете към Proxy или Browser endpoint. |
client_error |
Не | Request ще се провали отново по същия начин. Коригирайте входните данни. |
rate_limit |
Да | Спазвайте retryAfter от тялото на response. |
service_error |
Да | Кратко експоненциално изчакване (exponential backoff). |
service_fail |
Да | Същото като при service_error. |
Свързани теми
- API Errors: Грешки при responses на ниво HTTP
- Rate Limits: Какво задейства
rate_limit - Metrics: Къде можете да видите разбивка на резултатите
- Activity Log: История на резултатите за всяка request