Définir la question et les critères
Un moteur de recherche historique commence par une question, pas seulement par un champ de texte. Déterminez si l’utilisateur cherche des témoignages anciens, des mentions d’un produit ou des exemples de vocabulaire. Affichez clairement le caractère historique et indépendant des archives afin de ne pas suggérer une observation de l’activité actuelle de Reddit.
Choisissez une consultation de référence avec q, un subreddit et une période pertinente. Examinez quelques résultats avant de multiplier les variantes. Conservez les termes employés pour distinguer une différence de formulation d’une différence dans les données récupérées. L’API ne doit pas être présentée comme une interprétation automatique et complète de tous les sens possibles.
Décidez quels critères doivent être accessibles dès la première version. Le type de contenu et les dates peuvent suffire pour une recherche exploratoire. Si vous ajoutez min_score, décrivez le seuil et les exclusions qu’il produit. Ce filtre ne certifie ni la qualité du texte ni sa pertinence pour la question posée.
Organiser les appels et la navigation
Récupérez la clé lors de l’inscription et gardez-la sur le serveur de votre application. Elle est affichée avant paiement ; l’essai conditionnel, s’il est accordé, permet de tester quelques appels. Validez les entrées du formulaire et convertissez les dates en YYYY-MM-DD en UTC, avec to inclusif, avant d’envoyer la requête.
Commencez par une page pour observer les champs effectivement renvoyés. Lorsque l’utilisateur poursuit, conservez les mêmes filtres et respectez les limites de 100 enregistrements par requête et de 100 pages par recherche. Présentez la fin du parcours autorisé comme une limite de consultation, pas comme la preuve que tous les enregistrements ont été lus.
Faites dépendre l’affichage du total de sa relation. eq indique un total exact pour la recherche, gte une borne inférieure, unknown l’absence de total fiable. Un indicateur de progression ne doit pas utiliser une borne inférieure comme dénominateur exact. L’ordre documentaire des archives ne justifie pas non plus une étiquette « les plus récents ».
Vérifier l’expérience et les conclusions
Préparez des messages distincts pour une réponse vide et une erreur. Une réponse vide réussie consomme un crédit et concerne les critères employés. Pour 400, vérifiez les paramètres ; pour 401, la clé ; pour 402, le solde ; pour 429, réduisez le rythme et limitez les nouvelles tentatives. Évitez une répétition automatique de toutes les erreurs.
Si votre interface regroupe des commentaires, utilisez localement parent_id et link_id lorsqu’ils sont présents. Signalez les relations manquantes : les réponses sont plates et ne garantissent pas une conversation complète. Le découpage en périodes doit également rester une méthode d’organisation, sans devenir une promesse d’extraction exhaustive ou de résultats sans doublons.
Avant la mise à disposition, testez les filtres trop restrictifs, les totaux inconnus, la dernière page autorisée et les coupures de connexion. Comptez toutes les récupérations réussies dans le budget, y compris les répétitions et les réponses vides. Documentez les critères et la date d’exécution pour rendre les observations compréhensibles, sans garantir leur reproduction à l’identique.
