Accès et Authentification Sécurisés
Envoyez des requêtes GET à api.subredditapi.com avec Authorization: Bearer <clé> ou X-API-Key: <clé> pour les récupérations authentifiées. /v1/status est public et n’exige pas de clé. La session du panneau de compte utilise un cookie Secure HttpOnly distinct de ces en-têtes. Clé et solde sont propres à ce domaine et ne se partagent pas entre marques.
Chaque récupération réussie coûte un crédit, même vide. Les requêtes invalides ne débitent pas le solde ; les défaillances du fournisseur de recherche restituent la réserve. Une rupture de connexion du client peut suivre un succès facturé côté serveur. Chaque nouvelle tentative réussie coûte un autre crédit. Vérifiez le statut HTTP avant de traiter le corps comme des enregistrements.
400 indique des paramètres invalides, 401 une clé absente ou invalide, 402 un solde insuffisant et 429 une limite de fréquence. Corrigez la cause avant de répéter l’appel et limitez les tentatives. Les contrôles anti-abus de l’essai de 100 crédits s’appliquent au réseau ; ils ne doivent pas être confondus avec la limitation de fréquence signalée par 429.
Structuration des Données et Tri des Enregistrements
Les réponses de l'API retournent des enregistrements plats, ce qui signifie qu'ils ne sont pas pré-assemblés en arbres de fil hiérarchiques comme sur le site officiel. Les champs parent_id et link_id peuvent être présents, permettant au client de regrouper les données localement selon ses besoins. Aucun filtre de requête n'expose directement ces identifiants pour les requêtes simples de posts ou de commentaires.
L’ordre _doc est documentaire interne, ni chronologique ni fondé sur la pertinence ou le score. limit et page vont de 1 à 100 : une requête reçoit une page comportant au maximum 100 enregistrements. Un numéro de page ne fige pas l’archive. Même le parcours des pages autorisées ne prouve pas un résultat complet ou sans doublons.
eq indique un total exact pour la recherche, gte une borne inférieure et unknown l’absence de total fiable, éventuellement nul. Une borne inférieure n’est pas une estimation approximative. Aucun de ces états ne prouve la couverture des archives. Les agrégations de communautés ne garantissent pas non plus des comptes globaux exacts. Conservez cette information avec la sélection étudiée.
Filtres Spécifiques et Gestion des Crédits
Les filtres de recherche sont q, subreddit, author, kind, from, to, min_score, limit et page. kind accepte post ou comment. Les dates sont au format YYYY-MM-DD en UTC, avec to inclusif. min_score applique une valeur minimale de score, sans trier ni garantir la pertinence ou la qualité des textes retenus.
Utilisez /v1/search, /v1/posts et /v1/comments pour les recherches et listes. Seul /v1/item exige id ; /v1/subreddits accepte prefix et limit pour explorer les noms. Les filtres author et kind ne s’appliquent pas à cette découverte. parent_id et link_id ne sont pas des filtres exposés pour récupérer tous les commentaires d’une publication connue.
/v1/status renvoie une déclaration statique du périmètre historique et indique que l’application HTTP répond. Il est public et non facturé, mais ne teste pas la recherche ou la présence des enregistrements. L’API n’effectue pas de comparaison ou d’analyse de sentiment côté serveur ; les traitements des textes reçus appartiennent à votre application et à votre protocole de recherche.
Deux communautés, critères documentés
Essayez /v1/search?q=soil&subreddit=gardening&limit=3, puis modifiez seulement subreddit si cette variable est celle que vous comparez. Conservez terme, type, dates et seuils. Notez les textes manquants et décisions de traduction au lieu de compter une absence comme un choix de vocabulaire. Sauvegardez les réponses et la version des règles locales : les mêmes paramètres ne garantissent pas des réponses futures identiques.
