aippealing companies template
1.0.0
API para criar imagens atraentes de produtos da empresa feitos de chocolate, ouro ou LEGO. A implementação de referência é baseada no OpenAI (Dall-E, GPT-3).
Existem alguns produtos incríveis e visualmente atraentes da empresa feitos de chocolate ou lego
Inspirado nos recursos de geração de imagem e texto do OpenAI, esta API gera imagens dos produtos, as empresas são mais conhecidas e as transforma em ouro, chocolate, lego ou qualquer outro material.
Siga a documentação da API gerada e clique no botão "Executar no Postman"
Este servidor foi gerado usando o projeto gerador OpenAPI. O gerador de código, e seu código gerado permite que você desenvolva seu sistema com uma atitude de API-primeiro, onde o contrato da API é a âncora e definidora do seu projeto, e seu código e lógica de negócios visa concluir e cumprir os termos em termos em o contrato da API.
Nodejs> = 10.6
Npm> = 6.10.0
O código foi gravado em um Mac, portanto, supondo que tudo deve funcionar sem problemas em computadores baseados em Linux. No entanto, não há razão para não executar esta biblioteca em máquinas baseadas no Windows. Se você encontrar um problema relacionado ao sistema operacional, abra um problema e ele será resolvido.
Use o gerador OpenAPI para gerar seu aplicativo: supondo que você tenha Java (1.8+) e tenha o frasco para gerar o aplicativo, executar: 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} Se você o fizer Não tem o frasco ou não deseja executar o Java da sua máquina local, siga as instruções na página OpenApitools. Você pode executar o script on -line, no Docker e em várias outras maneiras.
Vá para o diretório gerado que você definiu. Há um servidor NodeJS-ExpressJS totalmente funcionando esperando por você. Isso é importante - o código é seu para alterar e atualizar! Veja o config.js e veja que as configurações estão bem com você - o servidor será executado na porta 3000 e os arquivos serão enviados para um novo diretório 'Upload_files'.
O servidor se baseará em um arquivo OpenApi.yaml, localizado em /api/openapi.yaml. Este não é exatamente o mesmo arquivo que você usou para gerar o aplicativo: I. Se você possui application/json Contentbody que foi definido dentro do objeto Path - o Gerate o terá movido para a seção de componentes/esquemas do documento OpenAPI. Ii. Todo processo possui um novo elemento adicionado a ele- x-eov-operation-handler: controllers/PetController que direciona a chamada para esse arquivo. Iii. Temos um aplicativo Java que traduz o OperationId em um método e um script NodeJS que faz o mesmo processo para chamar esse método. Ambos estão convertendo o método em camelCase , mas podem ter discrepância. Por favor, preste atenção aos nomes do OperalID e veja que eles são representados nos controllers e diretórios services .
Reserve um tempo para entender a estrutura do aplicativo. Pode haver bugs, e pode haver configurações e lógicos de negócios que não atendem à sua expectativa. Em vez de despejar esta solução e procurar outra coisa - veja se você pode fazer com que o código gerado funcione para você. Para manter a explicação curta (uma explicação mais detalhada seguirá): o aplicativo começa com uma chamada para index.js (é aqui que você conectará o banco de dados posteriormente). Ele chama ExpressServer.js, que é onde o Express.js e o OpenApi-Validator entram em ação. Este é um arquivo importante. Aprenda. Todas as chamadas para pontos de extremidade que foram configurados no documento OpenApi.yaml vão para controllers/{name_of_tag_which_the_operation_was_associated_with}.js , que é um método muito pequeno. Todas as lógicas de negócios estão em controllers/Controller.js , e a partir daí - para services/{name_of_tag_which_the_operation_was_associated_with}.js .
Depois de entender o que vai acontecer, inicie o aplicativo e verifique se tudo está funcionando como esperado:
npm start
(Assumindo que nenhuma alteração foi feita para config.js)
Documentação da API e, para verificar os terminais disponíveis: http: // localhost: 3000/api-docs/. Para
Faça o download do documento OpenApi.yaml: http: // localhost: 3000/OpenApi.
Cada chamada para um terminal definida no documento OpenAPI retornará uma lista de 200 e uma lista de todos os parâmetros e objetos que foram enviados na solicitação.
Os pontos de extremidade que exigem segurança precisam configurar os manipuladores de segurança antes que possam retornar uma resposta bem -sucedida. Neste ponto, eles retornarão um código de resposta de 401.
No diretório raiz, temos (além do package.json, config.js e arquivos de log):
Logger.js - onde definimos o logger do projeto. O projeto usa Winston, mas o objetivo deste arquivo é permitir que os usuários alterem e modifiquem seu próprio comportamento de logger.
Index.js - Este é o arquivo 'principal' do projeto e daqui lançamos o aplicativo. Este é um arquivo muito curto e conciso, e a idéia por trás do lançamento deste arquivo curto é permitir casos de uso para iniciar o servidor com parâmetros diferentes (alterando a configuração e/ou o Logger) sem afetar o restante do código.
ExpressServer.js - O núcleo do servidor Express.js. É aqui que o servidor Express é inicializado, juntamente com o Validador Openapi, OpenAPI UI e outras bibliotecas necessárias para iniciar nosso servidor. Se queremos adicionar links externos, é para onde eles iriam. Nosso projeto usa a Biblioteca Express-Openapi-Validator que atua como uma primeira etapa no processo de roteamento-solicitações direcionadas aos caminhos definidas no arquivo openapi.yaml são capturadas por esse processo, e seus parâmetros e contexto corporal são validados contra o esquema . Um resultado bem -sucedido dessa validação será um novo objeto 'OpenAPI' adicionado à solicitação. Se o caminho solicitado não fizer parte do arquivo OpenApi.yaml, o validador ignora a solicitação e o passa, como está, no fluxo do servidor Express.
OpenApi.yaml - Este é o contrato OpenAPI ao qual esse servidor será cumprido. O arquivo foi gerado usando o código e deve conter tudo o que é necessário para executar o gateway da API - sem referências a modelos/esquemas externos.
Atualmente um único arquivo:
OpenApirouter.js - É aqui que o roteamento para o nosso código de back -end acontece. Se o objeto de solicitação incluir um objeto openapi , ele captará os seguintes valores (que fazem parte do arquivo openapi.yaml ): 'X-Openapi-Router-Controller' e 'X-Openapi-Router-Service'. Essas variáveis são nomes de arquivos/classes nos diretórios de controladores e serviços, respectivamente. O operador da solicitação também é extraído. O OperationId é um método no controlador e o serviço que foi gerado como parte do processo CodeGen. O processo de roteamento envia os objetos de solicitação e resposta ao controlador, que extrairá as variáveis esperadas da solicitação e a enviará para ser processada pelo serviço, retornando a resposta do serviço ao chamador.
Depois de validar a solicitação e garantir que isso pertence ao nosso gateway da API, enviamos a solicitação a um controller , onde as variáveis e parâmetros são extraídos da solicitação e enviados ao service relevante para processamento. O controller lida com a resposta do service e cria a resposta HTTP apropriada a ser enviada de volta ao usuário.
Index.js - Carregue todos os controladores que foram gerados para este projeto e exportá -los para serem usados dinamicamente pelo openapiRouter.js . Se você deseja personalizar seu controlador, é aconselhado que você vincule ao seu controlador aqui e verifique se o codegen não reescreve esse arquivo.
Controller.js - O processador principal dos controladores gerados. Os controladores gerados são projetados para serem o mais finos e genéricos possível, referenciando o Controller.js para a lógica de negócios de analisar as variáveis e argumentos necessários da solicitação e para criar a resposta HTTP que será enviada de volta. O Controller.js é uma classe com métodos estáticos.
.js - código gerado automaticamente, processando todas as operações. O controlador é uma classe que é construída com a classe de serviço para a qual estará enviando a solicitação. Cada solicitação definida pelo openapi.yaml possui um OperationId. O OperationId é o nome do método que será chamado. Todo método recebe a solicitação e a resposta e chama o Controller.js para processar a solicitação e a resposta, adicionando o método de serviço que deve ser chamado para o processamento real-lógico de negócios.
É aqui que o gateway da API termina, e a Logica de Negócios exclusiva do seu aplicativo entra em ação. Todo ponto de extremidade no openapi.yaml possui uma variável 'X-Openapi-Router-Service', que é o nome da classe de serviço que é gerado. O operador do endpoint é o nome do método que será chamado. O código gerado fornece uma promessa simples com uma cláusula de tentativa/captura. Uma operação bem -sucedida termina com Service.js chamada para o Service.js genérico. Recomenda -se que os serviços sejam gerados automaticamente uma vez e após a compilação inicial, adicione métodos manualmente.
Index.js - Carregue todos os serviços gerados para este projeto e exportá -los para serem usados dinamicamente pelo openapiRouter.js . Se você deseja personalizar seu serviço, é aconselhado que você vincule ao seu controlador aqui e verifique se o codegen não reescreve esse arquivo.
Service.js - Uma classe de utilidade, muito simples e fina neste momento, com dois métodos estáticos para criar um objeto de resposta para resultados bem -sucedidos e falhados na operação de serviço. O código de resposta padrão é 200 para sucesso e 500 para falha. Recomenda -se enviar códigos de resposta mais precisos e substituir esses padrões quando relevantes.
.js - código gerado automaticamente, fornecendo uma promessa de stub para cada OperationId definido no openapi.yaml . Cada método recebe as variáveis definidas no arquivo openapi.yaml e envolve uma promessa em uma cláusula de tentativa/captura. A promessa resolve o sucesso e a falha em uma chamada para a classe Utility Service.js para criar a resposta apropriada que será enviada de volta ao controlador e, em seguida, ao chamador deste terminal.
SERVERTESTS.JS - Testes básicos de validação do servidor, verificando se o servidor está em alta, que uma chamada para um terminal dentro do escopo do arquivo openapi.yaml retorna 200, que um chamado para um caminho fora desse escopo retorna 200 se existir e um 404 se não.
ROTINGTESTS.JS - Executa todos os pontos de extremidade definidos no openapi.yaml e constrói uma solicitação dummy para enviar ao servidor. Confirma que o código de resposta é 200. Nesse ponto, solicitações contendo falhas XML ou FormData - atualmente elas não são suportadas no roteador.
AdicionalEndPointSstests.js - Um arquivo de teste para todos os pontos de extremidade definidos fora do escopo OpenApi.yaml. Confirma que esses pontos de extremidade retornam uma resposta de 200 bem -sucedida.
Testes futuros devem ser gravados para garantir que a resposta de cada solicitação enviada seja conforme à estrutura definida no openapi.yaml . Este teste falhará 100% inicialmente e o trabalho da equipe de desenvolvimento será limpar esses testes.
Atualmente, um conceito aguardando feedback. A idéia é definir os objetos definidos no OpenApi.yaml como modelos que são passados entre os diferentes módulos. Isso estará em conformidade com os programadores para interagir usando objetos definidos, em vez de objetos JSON de maneira vaga. Dada a natureza dos programadores JavaScript, que querem trabalhar com seus próprios parâmetros de bootstrat, esse conceito pode não funcionar. Mantendo isso aqui para futuras discussões e feedback.
