aippealing companies template
1.0.0
API Pour créer des images attrayantes de produits de l'entreprise en chocolat, or ou LEGO. L'implémentation de référence est basée sur OpenAI (Dall-E, GPT-3).
Il existe des produits de l'entreprise incroyables et visuellement attrayants en chocolat ou en LEGO
Inspirée par les capacités de génération d'image et de texte d'OpenAI, cette API génère des images des produits, les entreprises sont les plus connues et les transforment en or, chocolat, lego ou tout autre matériau.
Suivez la documentation de l'API générée et cliquez sur le bouton "Exécuter dans Postman"
Ce serveur a été généré à l'aide du projet Générateur OpenAPI. Le générateur de code, et son code généré vous permet de développer votre système avec une attitude API-First, où le contrat d'API est l'ancre et le définitif de votre projet, et votre code et votre entreprise commerciale visent à terminer et à se conformer aux termes en termes de le contrat de l'API.
Nodejs> = 10.6
Npm> = 6.10.0
Le code a été écrit sur un Mac, donc en supposant que tout devrait fonctionner en douceur sur les ordinateurs basés sur Linux. Cependant, il n'y a aucune raison de ne pas exécuter cette bibliothèque sur des machines Windows. Si vous trouvez un problème lié au système d'exploitation, veuillez ouvrir un problème et il sera résolu.
Utilisez le générateur OpenAPI pour générer votre application: en supposant que vous avez Java (1.8+) et que vous ayez le pot pour générer l'application, exécutez: java -jar {path_to_jar_file} generate -g nodejs-express-server -i {openapi yaml/json file} -o {target_directory_where_the_app_will_be_installed} Si vous n'avez pas le pot ou si vous ne souhaitez pas exécuter Java à partir de votre machine locale, suivez les instructions sur la page OpenApitools. Vous pouvez exécuter le script en ligne, sur Docker et diverses autres façons.
Accédez au répertoire généré que vous avez défini. Il y a un serveur NodeJS-ExpressJS entièrement qui vous attend. C'est important - le code vous appartient à changer et à mettre à jour! Regardez Config.js et voyez que les paramètres sont d'accord avec vous - le serveur s'exécutera sur le port 3000, et les fichiers seront téléchargés dans un nouveau répertoire «Téléchargé_files».
Le serveur se basera sur un fichier openapi.yaml qui est situé sous /api/openapi.yaml. Ce n'est pas exactement le même fichier que vous avez utilisé pour générer l'application: I. Si vous avez application/json ContentBody qui a été défini à l'intérieur de l'objet Path - le Generate l'a déplacé vers la section composants / schémas du document OpenAPI. Ii Chaque processus a un nouvel élément qui y est ajouté - x-eov-operation-handler: controllers/PetController qui dirige l'appel vers ce fichier. Iii. Nous avons une application Java qui traduit le OperationId en une méthode et un script NodeJS qui fait le même processus pour appeler cette méthode. Les deux convertissent la méthode en camelCase , mais peuvent avoir une différence. Veuillez faire attention aux noms OpérationID et voir qu'ils sont représentés dans les controllers et les répertoires services .
Prenez le temps de comprendre la structure de l'application. Il peut y avoir des bogues, et il pourrait y avoir des paramètres et des entreprises qui ne répondent pas à vos attentes. Au lieu de vider cette solution et de rechercher autre chose - voyez si vous pouvez faire fonctionner le code généré pour vous. Pour maintenir l'explication courte (une explication plus détaillée suivra): l'application commence par un appel à index.js (c'est là que vous brancherez la base de données plus tard). Il appelle ExpressServer.js, où se trouvent les express.js et openapi-validator. Il s'agit d'un fichier important. Apprenez-le. Tous les appels aux points de terminaison configurés dans le document OpenAPI.yaml vont aux controllers/{name_of_tag_which_the_operation_was_associated_with}.js , qui est une très petite méthode. Tout le domaine des entreprises dans controllers/Controller.js , et à partir de là - vers services/{name_of_tag_which_the_operation_was_associated_with}.js .
Une fois que vous avez compris ce qui va se passer, lancez l'application et assurez-vous que tout fonctionne comme prévu:
npm start
(En supposant qu'aucune modification n'a été apportée à config.js)
Documentation de l'API et pour vérifier les points de terminaison disponibles: http: // localhost: 3000 / api-docs /. À
Téléchargez le document OpenAPI.yaml: http: // localhost: 3000 / openapi.
Chaque appel à un point final défini dans le document OpenAPI renvoie un 200 et une liste de tous les paramètres et objets qui ont été envoyés dans la demande.
Les points de terminaison qui nécessitent la sécurité doivent avoir des assuffistes de sécurité configurés avant de pouvoir renvoyer une réponse réussie. À ce stade, ils retourneront un code de réponse de 401.
Dans le répertoire racine que nous avons (en plus de package.json, config.js et des fichiers journaux):
Logger.js - où nous définissons l'enregistreur du projet. Le projet utilise Winston, mais le but de ce fichier est de permettre aux utilisateurs de modifier et de modifier leur propre comportement d'enregistrement.
index.js - Il s'agit du fichier «principal» du projet, et à partir d'ici nous lançons l'application. Il s'agit d'un fichier très court et concis, et l'idée derrière le lancement à partir de ce court fichier est de permettre des cas d'utilisation du lancement du serveur avec différents paramètres (modification de la configuration et / ou de l'enregistreur) sans affecter le reste du code.
ExpressServer.js - Le cœur du serveur Express.js. C'est là que le serveur express est initialisé, avec le validateur OpenAPI, l'interface utilisateur OpenAPI et d'autres bibliothèques nécessaires pour démarrer notre serveur. Si nous voulons ajouter des liens externes, c'est là qu'ils iraient. Notre projet utilise la bibliothèque express-openapi-validator qui agit comme une première étape du processus de routage - les demandes qui sont dirigées vers les chemins définis dans le fichier openapi.yaml sont capturés par ce processus, et ses paramètres et le contenu corporel sont validés par rapport au schéma . Un résultat réussi de cette validation sera un nouvel objet «OpenAPI» ajouté à la demande. Si le chemin demandé ne fait pas partie du fichier OpenAPI.yaml, le validateur ignore la demande et le transmet, en bas du flux du serveur express.
OpenAPI.YAML - Il s'agit du contrat OpenAPI auquel ce serveur se conformera. Le fichier a été généré à l'aide du codeGen et doit contenir tout ce qui est nécessaire pour exécuter la passerelle API - pas de références aux modèles / schémas externes.
Actuellement un seul fichier:
openapirouter.js - C'est là que se produit le routage vers notre code back-end. Si l'objet de demande comprend un objet openapi , il ramasse les valeurs suivantes (qui font partie du fichier openapi.yaml ): 'x-openapi-router-contrôleur' et 'x-openapi-router-service'. Ces variables sont des noms de fichiers / classes dans les contrôleurs et répertoires de services respectivement. L'OpérationId de la demande est également extraite. Le OperationId est une méthode dans le contrôleur et le service généré dans le cadre du processus Codegen. Le processus de routage envoie les objets de demande et de réponse au contrôleur, qui extraire les variables attendues de la demande, et l'enverra pour être traitée par le service, renvoyant la réponse du service à l'appelant.
Après avoir validé la demande et garantir que cela appartient à notre passerelle API, nous envoyons la demande à un controller , où les variables et les paramètres sont extraits de la demande et envoyés au service pertinent pour le traitement. Le controller gère la réponse du service et construit la réponse HTTP appropriée à renvoyer à l'utilisateur.
index.js - Chargez tous les contrôleurs générés pour ce projet et exportez-les à être utilisés dynamiquement par openapiRouter.js . Si vous souhaitez personnaliser votre contrôleur, il est conseillé de créer un lien vers votre contrôleur ici et de vous assurer que le codeGen ne réécrit pas ce fichier.
Controller.js - Le processeur de base des contrôleurs générés. Les contrôleurs générés sont conçus pour être aussi minces et génériques que possible, faisant référence au Controller.js pour la logique métier de l'analyse des variables et des arguments nécessaires de la demande, et pour construire la réponse HTTP qui sera renvoyée. Le Controller.js est une classe avec des méthodes statiques.
.js - Code généré automatiquement, traitement de toutes les opérations. Le contrôleur est une classe construite avec la classe de service à laquelle il enverra la demande. Chaque demande définie par l' openapi.yaml a un OperationId. Le OperationId est le nom de la méthode qui sera appelée. Chaque méthode reçoit la demande et la réponse, et appelle le Controller.js pour traiter la demande et la réponse, en ajoutant la méthode de service qui doit être appelée pour le traitement réel Business-Logic.
C'est là que la passerelle API se termine, et la logique commerciale unique de votre application entre en jeu. Chaque point final de l' openapi.yaml a une variable «x-openapi-router-service», qui est le nom de la classe de service qui est généré. L'opération du point de terminaison est le nom de la méthode qui sera appelée. Le code généré fournit une promesse simple avec une clause Try / Catch. Une opération réussie se termine par un appel au Service.js générique.js pour créer une réponse réussie (charge utile et code de réponse), et un échec appellera le Service.js générique.js pour créer une réponse avec un objet d'erreur et le code de réponse pertinent. Il est recommandé d'avoir les services générés automatiquement une fois, et après la construction initiale, ajoutez des méthodes manuellement.
index.js - Chargez tous les services générés pour ce projet et exportez-les à être utilisés dynamiquement par openapiRouter.js . Si vous souhaitez personnaliser votre service, il est conseillé de créer un lien vers votre contrôleur ici et de vous assurer que le codeGen ne réécrit pas ce fichier.
Service.js - Une classe de services publics, très simple et mince à ce stade, avec deux méthodes statiques pour construire un objet de réponse pour les résultats réussis et échoués dans l'opération de service. Le code de réponse par défaut est 200 pour le succès et 500 pour l'échec. Il est recommandé d'envoyer des codes de réponse plus précis et de remplacer ces valeurs par défaut le cas échéant.
.js - Code généré automatiquement, fournissant une promesse de talon pour chaque operationid défini dans l' openapi.yaml . Chaque méthode reçoit les variables définies dans le fichier openapi.yaml et enveloppe une promesse dans une clause Try / Catch. La promesse résout à la fois le succès et l'échec dans un appel à la classe d'utilité Service.js pour construire la réponse appropriée qui sera renvoyée au contrôleur, puis à l'appelant de ce point de terminaison.
SERVERTESTS.JS - Tests de validation du serveur de base, vérifiant que le serveur est passé, qu'un appel à un point final dans le cadre du fichier openapi.yaml renvoie 200, qu'un appel à un chemin à l'extérieur de cette portée renvoie 200 s'il existe et un 404 Sinon.
Routingtests.js - exécute tous les points de terminaison définis dans openapi.yaml et construit une demande factice à envoyer au serveur. Confirme que le code de réponse est de 200. À ce stade, les demandes contenant du XML ou FormData échouent - actuellement elles ne sont pas prises en charge dans le routeur.
AdditionDendPointStsS.js - Un fichier de test pour tous les points de terminaison définis en dehors de la portée openapi.yaml. Confirme que ces points finaux renvoient une réponse réussie de 200.
Les tests futurs doivent être rédigés pour s'assurer que la réponse de chaque demande envoyée doit être conforme à la structure définie dans l' openapi.yaml . Ce test échouera à 100% initialement, et le travail de l'équipe de développement sera d'effacer ces tests.
Actuellement un concept en attente de commentaires. L'idée est que les objets définissent dans l'OpenAPI.yaml agissent comme des modèles qui sont passés entre les différents modules. Cela conformera les programmeurs pour interagir à l'aide d'objets définis, plutôt que des objets JSON définis de manière lâche. Compte tenu de la nature des programmeurs JavaScript, qui veulent travailler avec leurs propres paramètres bootstrapés, ce concept pourrait ne pas fonctionner. Garder cela ici pour les discussions et les commentaires futurs.
