aippealing companies template
1.0.0
API para crear imágenes atractivas de productos de la compañía hechos de chocolate, oro o LEGO. La implementación de referencia se basa en OpenAI (Dall-E, GPT-3).
Hay algunos productos increíbles y visualmente atractivos hechos de chocolate o lego.
Inspirada en las capacidades de generación de imágenes y texto de OpenAI, esta API genera imágenes de los productos, las empresas son más conocidas y las convierte en oro, chocolate, lego o cualquier otro material.
Siga la documentación de API generada y haga clic en el botón "Ejecutar en Postman"
Este servidor se generó utilizando el proyecto OpenAPI Generator. El generador de código, y su código generado le permite desarrollar su sistema con una actitud API-First, donde el contrato de API es el ancla y definición de su proyecto, y su código y el logic de negocios tienen como objetivo completar y cumplir con los términos en el contrato de API.
Nodejs> = 10.6
Npm> = 6.10.0
El código fue escrito en una Mac, por lo que suponiendo que todo debería funcionar sin problemas en las computadoras basadas en Linux. Sin embargo, no hay razón para no ejecutar esta biblioteca en máquinas basadas en Windows. Si encuentra un problema relacionado con el sistema operativo, abra un problema y se resolverá.
Use el generador OpenAPI para generar su aplicación: suponiendo que tenga Java (1.8+) y tenga el jar para generar la aplicación, ejecute: 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} if No tiene el frasco, o no desea ejecutar Java desde su máquina local, siga las instrucciones en la página de Openapitools. Puede ejecutar el script en línea, en Docker y varias otras maneras.
Vaya al directorio generado que definió. Hay un servidor NodeJS-ExpressJS completamente en funcionamiento que lo espera. Esto es importante: ¡el código es suyo para cambiar y actualizar! Mire a config.js y vea que la configuración allí está bien con usted: el servidor se ejecutará en el puerto 3000, y los archivos se cargarán en un nuevo directorio 'uploaded_files'.
El servidor se basará en un archivo Openapi.yaml que se encuentra en /api/openapi.yaml. Este no es exactamente el mismo archivo que usó para generar la aplicación: I. Si tiene application/json ContentBody que se definió dentro del objeto de ruta: la generación lo habrá trasladado a la sección de componentes/esquemas del documento OpenAPI. II. Cada proceso tiene un nuevo elemento agregado: x-eov-operation-handler: controllers/PetController que dirige la llamada a ese archivo. Iii. Tenemos una aplicación Java que traduce el OperationId a un método y un script NodeJS que hace el mismo proceso para llamar a ese método. Ambos están convirtiendo el método en camelCase , pero pueden tener discrepancia. Preste atención a los nombres de operación y vea que están representados en los directorios de controllers y services .
Tómese el tiempo para comprender la estructura de la aplicación. Puede haber errores, y puede haber configuraciones y lógicos de negocios que no cumplan con sus expectativas. En lugar de deshacerse de esta solución y buscar algo más, vea si puede hacer que el código generado funcione para usted. Para mantener la explicación corta (seguirá una explicación más detallada): la aplicación comienza con una llamada a index.js (aquí es donde conectará el DB más adelante). Llama a ExpressServer.js, que es donde se activan el Express.js y OpenApi-Validator. Este es un archivo importante. Aprenda. Todas las llamadas a puntos finales que se configuraron en el documento OpenApi.yaml van a controllers/{name_of_tag_which_the_operation_was_associated_with}.js , que es un método muy pequeño. Todo el Logic de negocios se encuentra en controllers/Controller.js , y desde allí - a services/{name_of_tag_which_the_operation_was_associated_with}.js .
Una vez que haya entendido lo que va a suceder, inicie la aplicación y asegúrese de que todo funcione como se esperaba:
npm start
(Suponiendo que no se hicieron cambios en config.js)
Documentación de API, y para verificar los puntos finales disponibles: http: // localhost: 3000/api-docs/. A
Descargue el documento Openapi.yaml: http: // localhost: 3000/openapi.
Cada llamada a un punto final que se definió en el documento de OpenAPI devolverá un 200 y una lista de todos los parámetros y objetos que se enviaron en la solicitud.
Los puntos finales que requieren seguridad necesitan tener controladores de seguridad configurados antes de que puedan devolver una respuesta exitosa. En este punto, devolverán un código de respuesta de 401.
En el directorio raíz tenemos (además de paquete.json, config.js y archivos de registro):
Logger.js : donde definimos el registrador para el proyecto. El proyecto usa Winston, pero el propósito de este archivo es permitir a los usuarios cambiar y modificar su propio comportamiento del registrador.
index.js : este es el archivo 'principal' del proyecto, y desde aquí lanzamos la aplicación. Este es un archivo muy corto y conciso, y la idea detrás del lanzamiento de este archivo corto es permitir casos de uso del lanzamiento del servidor con diferentes parámetros (cambiando la configuración y/o el registrador) sin afectar el resto del código.
ExpressServer.js - El núcleo del servidor Express.js. Aquí es donde se inicializa el servidor Express, junto con el validador de OpenApi, la interfaz de usuario de OpenApi y otras bibliotecas necesarias para iniciar nuestro servidor. Si queremos agregar enlaces externos, ahí es donde irían. Nuestro proyecto utiliza la biblioteca Express-Openapi-Validator que actúa como un primer paso en el proceso de enrutamiento: las solicitudes que se dirigen a rutas definidas en el archivo openapi.yaml son capturados por este proceso, y sus parámetros y contenido de body se validan contra el esquema . Un resultado exitoso de esta validación será un nuevo objeto 'OpenAPI' agregado a la solicitud. Si la ruta solicitada no es parte del archivo OpenApi.yaml, el validador ignora la solicitud y la pasa, tal como está, en el flujo del servidor expreso.
OpenApi.yaml : este es el contrato de OpenAPI al que cumplirá este servidor. El archivo se generó utilizando el Codegen, y debe contener todo lo necesario para ejecutar la puerta de enlace API, sin referencias a modelos/esquemas externos.
Actualmente un solo archivo:
OpenApirouter.js : aquí es donde ocurre el enrutamiento a nuestro código de fondo. Si el objeto de solicitud incluye un objeto openapi , recoge los siguientes valores (que son parte del archivo openapi.yaml ): 'X-Openapi-Router-Controller' y 'X-Openapi-Router-Service'. Estas variables son nombres de archivos/clases en los directorios de controladores y servicios, respectivamente. También se extrae la operación de la solicitud. El operatorID es un método en el controlador y el servicio que se generó como parte del proceso Codegen. El proceso de enrutamiento envía los objetos de solicitud y respuesta al controlador, que extraerá las variables esperadas de la solicitud, y lo enviará a procesar por el servicio, devolviendo la respuesta del servicio al llamado.
Después de validar la solicitud y garantizar que esto pertenezca a nuestra puerta de enlace API, enviamos la solicitud a un controller , donde las variables y los parámetros se extraen de la solicitud y se envían al service correspondiente para su procesamiento. El controller maneja la respuesta del service y construye la respuesta HTTP apropiada que se enviará al usuario.
Index.js : cargue todos los controladores que se generaron para este proyecto y exportenlos para que los usen dinámicamente por openapiRouter.js . Si desea personalizar su controlador, se recomienda que vincule a su controlador aquí y asegúrese de que Codegen no reescriba este archivo.
Controler.js : el procesador central de los controladores generados. Los controladores generados están diseñados para ser lo más delgados y genéricos como sea posible, haciendo referencia al Controller.js para la lógica comercial de analizar las variables y argumentos necesarios de la solicitud, y para construir la respuesta HTTP que se enviará de regreso. El Controller.js es una clase con métodos estáticos.
.JS - Código generado automático, procesando todas las operaciones. El controlador es una clase que se construye con la clase de servicio a la que enviará la solicitud. Cada solicitud definida por openapi.yaml tiene un operatorID. El operatorID es el nombre del método que se llamará. Cada método recibe la solicitud y la respuesta, y llama al Controller.js para procesar la solicitud y la respuesta, agregando el método de servicio que debe llamarse para el procesamiento real de negocios.
Aquí es donde termina la puerta de enlace de la API, y el lógico de negocios único de su aplicación se activa. Cada punto final en openapi.yaml tiene una variable 'X-Openapi-Router-Service', que es el nombre de la clase de servicio que es generado. La operación del punto final es el nombre del método que se llamará. El código generado proporciona una promesa simple con una cláusula Try/Catch. Una operación exitosa finaliza con una llamada al Service.js genérico.js para crear una respuesta exitosa (código de carga y respuesta), y una falla llamará al Service.js genérico.js para crear una respuesta con un objeto de error y el código de respuesta relevante. Se recomienda que los servicios se generen automáticamente una vez, y después de la compilación inicial, agregue los métodos manualmente.
index.js : cargue todos los servicios que se generaron para este proyecto y los exporten para que los usen dinámicamente por openapiRouter.js . Si desea personalizar su servicio, se recomienda que vincule a su controlador aquí y se asegure de que Codegen no reescribe este archivo.
Service.js : una clase de utilidad, muy simple y delgada en este punto, con dos métodos estáticos para construir un objeto de respuesta para resultados exitosos y fallidos en la operación de servicio. El código de respuesta predeterminado es 200 para el éxito y 500 para la falla. Se recomienda enviar códigos de respuesta más precisos y anular estos valores predeterminados cuando sea relevante.
.js - Código generado automático, proporcionando una promesa de trozo para cada operator definido en openapi.yaml . Cada método recibe las variables que se definieron en el archivo openapi.yaml , y envuelve una promesa en una cláusula de prueba/captura. La promesa resuelve tanto el éxito como el fracaso en una llamada a la clase de servicios públicos Service.js para construir la respuesta apropiada que se enviará al controlador y luego a la persona que llama a este punto final.
SERVERTESTS.JS - Pruebas básicas de validación del servidor, verificando que el servidor está activo, que una llamada a un punto final dentro del alcance del archivo openapi.yaml devuelve 200, que una llamada a una ruta fuera de ese alcance devuelve 200 si existe y un 404 si no.
RoutingTests.js : se ejecuta a través de todos los puntos finales definidos en openapi.yaml y construye una solicitud ficticia para enviar al servidor. Confirma que el código de respuesta es 200. En este punto, las solicitudes que contienen XML o FormData Fail, actualmente no son compatibles con el enrutador.
Add adicionalDpointStests.js : un archivo de prueba para todos los puntos finales que se definen fuera del alcance de Openapi.yaml. Confirma que estos puntos finales devuelven una respuesta exitosa de 200.
Se deben escribir pruebas futuras para garantizar que la respuesta de cada solicitud enviada debe ajustarse a la estructura definida en openapi.yaml . Esta prueba fallará 100% inicialmente, y el trabajo del equipo de desarrollo será eliminar estas pruebas.
Actualmente un concepto que espera comentarios. La idea es tener los objetos definidos en Openapi.yaml actúa como modelos que se pasan entre los diferentes módulos. Esto conformará a los programadores para interactuar utilizando objetos definidos, en lugar de objetos JSON sueltos definidos. Dada la naturaleza de los programadores de JavaScript, que desean trabajar con sus propios parámetros de arranque, este concepto podría no funcionar. Manteniendo esto aquí para futuras discusiones y comentarios.
