Guide d'intégration
Une API est utile lorsque votre application doit envoyer des tâches et traiter les résultats sans répéter chaque action manuellement. Utilisez ce guide pour déterminer où Evolink pourrait s'intégrer, ce qu'il faut vérifier dans sa documentation et comment tester un flux de travail ciblé avant de construire votre application autour de ce service.
Commencez par définir le résultat souhaité, puis décidez si un outil direct ou un flux de travail répétable dans votre application est plus adapté.
Une intégration peut supprimer les transferts répétitifs, mais elle ne peut ni rendre disponible un flux de travail non pris en charge ni garantir que chaque résultat sera utilisable.
Une fonctionnalité visible dans une interface web ne dispose pas nécessairement d'un point de terminaison correspondant. C'est la documentation d'Evolink, et non une capture d'écran de l'interface, qui doit déterminer ce que votre application peut appeler.
Solution de contournement
Dressez la liste des entrées et des sorties nécessaires, puis vérifiez chacune d'elles dans la documentation actuelle des points de terminaison.
Le contenu généré peut varier selon l'invite, le contenu source et le modèle choisi. Une requête réussie ne signifie pas à elle seule que le résultat répond à vos critères éditoriaux ou techniques.
Solution de contournement
Examinez un petit ensemble de résultats représentatifs et ajoutez une étape de validation humaine lorsque l'exactitude est importante.
Un flux de travail en production doit aussi gérer les entrées rejetées, les requêtes interrompues et les réponses que votre application ne peut pas traiter. Ne supposez pas qu'un seul exemple où tout se passe bien couvre ces cas.
Solution de contournement
Testez les réponses en cas d'échec et déterminez quand réessayer, modifier l'entrée ou arrêter.
Gardez le premier test Evolink suffisamment limité pour pouvoir examiner à la fois l’entrée envoyée et le résultat renvoyé.
Choisissez une tâche répétable unique et notez ses données d’entrée requises, son résultat attendu et ses critères d’acceptation. Évitez de combiner plusieurs types de contenu lors du premier test.
Consultez la documentation API actuelle pour connaître le format de la requête et de la réponse concernés, la méthode d’authentification et les limites documentées. Considérez le code d’exemple comme un point de départ, et non comme la spécification.
Envoyez une requête représentative, enregistrez la réponse et vérifiez si le résultat peut être transmis à l’étape suivante de votre flux de travail. Recommencez avec une entrée non valide pour voir comment l’échec est signalé.
La distinction utile se situe entre le contenu que vous envoyez et le résultat que votre flux de travail doit ensuite évaluer.
Espace de travail des entrées
Exemple de résultat
Une interface directe peut être plus simple pour un usage occasionnel. Une API mérite d’être évaluée lorsqu’une application doit transmettre des entrées et des résultats entre des étapes répétables.
Démarrage d’une tâche
Flux de travail manuel
Une personne saisit les données d’entrée dans une interface.
Flux de travail avec API
Une application prépare et envoie les données d’entrée.
Répétabilité
Flux de travail manuel
La personne répète les mêmes actions.
Flux de travail avec API
L’application peut réutiliser un modèle de requête défini.
Traitement des résultats
Flux de travail manuel
Une personne examine le résultat et le transmet à l’étape suivante.
Flux de travail via l’API
Le code reçoit le résultat pour vérification ou pour une autre étape.
Effort de configuration
Flux de travail manuel
Peu de configuration technique est nécessaire pour une tâche individuelle.
Flux de travail via l’API
Le développement et les tests sont nécessaires.
Gestion des erreurs
Flux de travail manuel
Une personne remarque les problèmes au cours de son travail.
Flux de travail via l’API
L’application doit gérer explicitement les erreurs.
Meilleur point de départ
Flux de travail manuel
Explorer une tâche et évaluer quelques résultats.
Flux de travail via l’API
Automatiser une tâche une fois ses entrées et ses critères de vérification définis.
Il s’agit de flux de travail potentiels à étudier, et non d’affirmations selon lesquelles chaque fonctionnalité mentionnée dispose d’un point de terminaison Evolink documenté.
Un producteur rassemble de courtes descriptions de scènes et souhaite disposer d’une méthode cohérente pour soumettre chacune d’elles à la génération.
Vérifiez le flux de travail vidéo et les commandes disponibles avant de concevoir le passage de relais.
générateur de vidéos IAUn chargé de recherche doit distinguer l’outil Evolink dans son ensemble d’une méthode d’intégration précise.
Déterminez quelle tâche mérite d’être testée avant d’écrire le code de l’application.
evolink IAUn développeur cherche un exemple de requête, mais doit savoir s’il correspond à la documentation actuelle.
Comparez les exemples avec les requêtes et réponses décrites dans la documentation avant de les adapter.
exemples evolink githubEssayez une entrée représentative, examinez le résultat et déterminez si Evolink convient à la prochaine étape de votre processus. Limitez la portée du premier test pour repérer facilement les commandes manquantes ou les résultats inattendus.
Essayez l’outilVérifiez que la documentation actuelle couvre la tâche que vous souhaitez automatiser. Examinez les entrées requises, les données renvoyées, la méthode d’authentification et les éventuelles limites d’utilisation documentées avant d’arrêter la conception de votre application.
Pas toujours. Une interface directe est souvent plus simple pour explorer une tâche, tandis qu’une API est plus utile lorsque votre application nécessite un passage de relais reproductible. Testez d’abord le flux de travail manuel si vous ne savez pas encore à quoi ressemble un bon résultat.
Un exemple peut montrer la structure d’une requête, mais il peut ne pas couvrir les entrées non valides ou les réponses inattendues. Comparez-le à la documentation actuelle et testez les requêtes qui réussissent comme celles qui échouent avant de vous y fier.
Ne vérifiez pas seulement si une requête aboutit. Examinez les données renvoyées, vérifiez que votre application peut les utiliser et comparez le résultat aux critères d’acceptation que vous avez définis pour la tâche.