← Tous les articles
Mise à jour produit 5 min de lecture

Les règles de validation définissent désormais le succès

Déclarez quelles réponses comptent comme un succès avec les règles de validation. Les réponses non-200 acceptées sont facturées correctement et s'affichent comme succès dans votre flux d'activité.

apivalidationoutcomesbilling

Les règles validate de votre requête pilotent maintenant la classification de chaque résultat. Déclarez une 403 comme acceptable, et une 403 reçue compte comme un succès, est facturée comme un succès, et arrive dans votre flux d'activité avec vos 200.

Cela semble mineur. Cela change votre façon de mesurer la précision du scraping à grande échelle.

Fonctionnement

Chaque requête vers FourA obtient l'un des sept résultats qui déterminent la facturation et les analyses. Seul success est facturable. Le reste est réparti selon la responsabilité de l'échec :

  • application_fail et application_error quand le site cible refuse ou renvoie un corps d'erreur
  • client_error quand la requête envoyée était malformée
  • service_fail, service_error, et rate_limit quand un élément de notre côté a bloqué la requête

Avant ce changement, le succès signifiait une seule chose : HTTP 200. Une 403 était toujours application_fail, même si vous saviez que cette 403 était la réponse voulue. (Certaines APIs de données sportives renvoient 403 pour les marchés géo-restreints, et c'est le signal que votre code attend.)

Maintenant, votre bloc validate décide. La requête exécute vos règles pendant l'exécution. Si la réponse les satisfait, le résultat est success.

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/api/feed",
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 403] },
      "data": { "fail": ["captcha", "Access Denied"] }
    }
  }'

Cela traite 200 et 403 comme des codes de statut valides. Si le corps contient un marqueur CAPTCHA ou une chaîne d'accès refusé, la requête échoue. Tout le reste est success.

Deux règles à retenir :

  1. Sans validate, le comportement est inchangé. Les requêtes qui ne déclarent pas de validation sont toujours facturées uniquement sur HTTP 200. Vous devez l'activer.
  2. validate fonctionne dans les deux sens. Les règles d'acceptation passent, les règles d'échec rejettent. Elles se composent. Vous pouvez donc accepter [200, 403] et tout de même échouer quand le corps contient le mauvais contenu.

Impact

Ce changement est essentiel pour les équipes dont les cibles renvoient des réponses non-200 qu'elles souhaitent réellement.

Exemples tirés des requêtes que nous voyons quotidiennement :

  • Les APIs de données sportives qui renvoient 403 pour les marchés géo-restreints (données toujours utiles, valant toujours la peine d'être enregistrées comme succès)
  • Les endpoints de recherche e-commerce qui renvoient 404 quand un SKU est en rupture de stock (un signal que votre code lit, pas un échec)
  • Les APIs de streaming et de contenu partiel qui renvoient 206

Avant le changement, ces équipes géraient leur propre comptabilité par-dessus nos journaux d'activité. Elles ne pouvaient pas faire confiance à la colonne outcome car leur définition du succès ne correspondait pas à la nôtre. Elles étaient facturées sur un chiffre qui ne les intéressait pas vraiment.

Maintenant, la colonne reflète la réalité. L'onglet d'activité de votre tableau de bord montre ce que vous avez défini comme succès, pas ce que nous avons deviné. Vos totaux facturés correspondent à ce que vous compteriez vous-même (premiers résultats : le changement ne s'applique que vers l'avant, les anciennes lignes d'activité conservent donc leur classification originale).

L'effet pratique sur une tâche de scraping : moins d'étapes de réconciliation entre votre pipeline et notre facture. Si vous exécutiez déjà une validation sur le corps de la réponse a posteriori, vous pouvez déplacer ce contrat dans la requête elle-même et arrêter de maintenir un ensemble parallèle de règles de réussite ou d'échec en dehors de notre API. Une seule définition pour savoir si une requête a gagné sa place dans votre jeu de données, au lieu de deux qui se contredisent.

Mais nous avons gardé le filet de sécurité. Si vous ne passez pas de bloc validate, rien ne change. Le classificateur revient à "200 signifie succès", de sorte que les requêtes qui fonctionnaient hier fonctionnent de la même manière aujourd'hui.

Pour les utilisateurs avancés

validate accepte trois ensembles de règles qui s'exécutent indépendamment : status, headers, et data. Chacun prend des listes optionnelles accept et fail.

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/9876",
    "followRedirects": 5,
    "unblocker": true,
    "validate": {
      "status": { "accept": [200, 304] },
      "headers": { "accept": { "content-type": "application/json" } },
      "data": { "accept": ["\"price\":"], "fail": ["maintenance", "captcha"] }
    }
  }'

Cela nécessite :

  • Le statut est 200 ou 304
  • La réponse annonce un type de contenu JSON
  • Le corps contient un champ de prix
  • Le corps ne contient pas d'avis de maintenance ou de piège captcha

Si une règle échoue, le résultat est application_fail. Si tout passe, c'est success. Le classificateur s'exécute dans la requête elle-même, vous évitez donc l'aller-retour qu'une étape de validation séparée coûterait.

Combiné avec followRedirects : suivez jusqu'à cinq sauts, puis validez la réponse finale. Une redirection trompeuse d'une URL propre vers un portail CAPTCHA échoue proprement au lieu de polluer votre jeu de données.

Et une astuce tirée de l'exécution de nos propres scrapers : déclarez les modèles data.fail de manière agressive. Un 200 OK avec un CAPTCHA à l'intérieur est le mode d'échec silencieux le plus courant sur les sites protégés. Traitez le corps comme faisant autorité, pas le code de statut.

Pour le schéma complet, la référence de requête liste chaque champ validate et comment chacun se compose.

Prochaines étapes

Nous travaillons sur des primitives de règles plus riches : des correspondances regex pour data, des prédicats JSON-path structurés, et une correspondance d'en-têtes plus souple. Le principe reste le même. Vous déclarez à quoi ressemble le succès, l'API le respecte de bout en bout, de la requête jusqu'à votre facture.

Quand votre scraper s'arrête, il devrait le signaler clairement. Et quand il fonctionne selon des règles que vous avez vous-même écrites, c'est un chiffre auquel vous pouvez réellement faire confiance.