serverest / serverest

APIs REST simulando loja virtual para servir de estudo de testes de API de forma manual ou automatizada

ServeRest

Servidor REST para estudo de testes de API

Código de conduta | Como contribuir | Histórico de alterações | Doadores

ServeRest permite o estudo de:

• Verbos GET, POST, PUT e DELETE com persistência de dados
• Teste de carga
• Autenticação no header
• Query string
• Teste de schema json

Ambientes disponíveis

Online em serverest.dev

Local com NPM

Local com docker

Consumindo o ServeRest

O ServeRest está disponível de forma online, no npm e no docker.

Todas essas opções possuem as mesmas rotas, regras, dados pré-cadastrados e documentação. Escolha a melhor opção para você.

No ambiente online os dados cadastrados são removidos diariamente, enquanto que no local basta reiniciar o ServeRest.

Prefira a opção de ambiente local caso precise que os dados não sejam alterados por outro usuário.

Online

Acesse https://serverest.dev para visualizar a documentação e as rotas disponíveis.

Essa é a melhor opção para quem não possui NPM e Docker na máquina ou não quer preocupar em gerenciar ambiente.

O ServeRest online possui monitoramento constante do status e tempo de atividade para garantir que esteja sempre disponível.

Localmente com NPM

Execute o seguinte comando no terminal:

npx serverest@latest

Abra para ver detalhes de configuração do ServeRest com NPM

Configuração

Para visualizar as configurações que são possíveis de serem feitas execute o comando:

npx serverest -h

Segurança (--nosec)

Por default, o ServeRest irá fazer as seguintes alterações no cabeçalho, que podem ser desabilitadas com npx serverest --nosec:

Cabeçalhos adicionados:

• Strict-Transport-Security: max-age=15552000; includeSubDomains
• X-Content-Type-Options: nosniff
• X-DNS-Prefetch-Control: off
• X-Download-Options: noopen
• X-Frame-Options: SAMEORIGIN
• X-XSS-Protection: 1; mode=block

Cabeçalho removido:

• X-Powered-By: Express

Utilize esse comportamento nos seus testes, validando a presença/ausência desses cabeçalhos.

Para saber mais leia o checklist de segurança de API

---

Localmente com docker

Execute o seguinte comando no terminal:

docker run -p 3000:3000 paulogoncalvesbh/serverest:latest

Para visualizar as configurações que são possíveis de serem feitas execute o comando:

docker run -p 3000:3000 paulogoncalvesbh/serverest:latest --help

Executando versão específica

Em ambos os comandos de subida de ambiente local será utilizado a última versão disponível. Caso queira usar uma versão específica basta substituir o latest pela versão desejada.

Você pode encontrar as versões disponíveis na lista de tags no Docker Hub e na lista de versões do NPM.

Teste de carga

IMPORTANTE

O teste de carga deve ser executado apenas em ambiente local (disponibilizado via NPM ou Docker e acessível via http://localhost:3000).

O não seguimento vai acarretar em prejuízo para o projeto open source e gratuito e irá impactar o estudo de outras pessoas.

Acesso ao status

Para acompanhar o comportamento do ServeRest diante dos seus testes você pode acessar a página http://localhost:3000/status, que contém informações como:

• Uso de CPU.
• Uso da memória.
• Tempo de resposta.
• RPS (Requisições por segundo).

A página de status (/status) está disponível apenas localmente.

Fez teste de carga? O que acha de compartilhar com o autor do projeto o repositório e o relatório final contendo dados de RPS para auxiliar o ServeRest a entender o comportamento de sua infra?

Badge

Criou repositório utilizando o ServeRest? Adicione o código abaixo no topo do README.md para ter a badge do projeto.

[![Badge ServeRest](https://img.shields.io/badge/API-ServeRest-green)](https://github.com/ServeRest/ServeRest/)

Exemplos de automação

Os repositórios abaixo são exemplos de automação com boas práticas e que consome o ServeRest.

• Java > Automação com REST-Assured e Junit - Lucas Fraga
• JS > Automação com Supertest, Mocha e Chai - Paulo Gonçalves
• JS > Automação com Playwright - Leonardo Tsuda
• Python > Automação com Pytest - Leonardo Tsuda
• Robot Framework > Automação com RequestsLibrary - Mayara Fernandes
• Ruby > Automação com HTTParty e RSpec - Bruno Quintanilha

Para encontrar mais repositórios acesse https://github.com/search?q=serverest&type=Repositories

Doadores

Achou o projeto útil? Faça doação única ou mensal a partir de 1 dólar e ajude a pagar o domínio, a hospedagem e a manutenção de https://serverest.dev.

Pessoas que apoiam o ServeRest:

Empresas que apoiam o ServeRest financeiramente:

Todos os apoiadores anteriores e atuais podem ser vistos no Open Collective do ServeRest.

Patrocínio com produtos

ServeRest é apoiado pelas seguintes empresas, que fornecem acesso aos seus produtos através de plano de apoio a projetos open source:

Contribuidores ✨

Veja aqui como você pode contribuir. Contribuições de qualquer tipo são bem-vindas!

Leandro Muto 📖 🚇	Felipe Rodrigues 🚇	Lucas Amaral 📢 🐛 📖	lucas.fraga 🤔 🐛	bruno batista 🤔	Elias Reis 🚧 🚇	gabriel-pinheiro 💻 🤔
Rafael Gomes 🚇	Diego Bandeira 🚇	Maximiliano Alves 📢	Murilo Maia 💻	Cristina Nazário 🤔 🐛	Eduardo Santos 💻	Renato Davoli 💻

serverest's Issues

Implementar entrega contínua (CD)

Descreva a solução que você deseja
Ter entrega contínua.
Ao realizar push para a master deve realizar todas as etapas necessárias e publicar no NPM.

Descreva as alternativas que você considerou

• Implementar o Semantic Release na CI para pushes na branch.
• Remover npm standard-version.
• Atualizar o contributing.md e informar sobre a CD.
• Incluir badge do semantic-release.

Importante

• Nesse workflow de CD deve realizar todas os jobs já criados, como lint, commitlint e testes. Se algum quebrar a release é abortada.
• Deve ser gerado changelog. Analisar como o semantic-release gera.

Material de apoio:

• NPM do Semantic-Release
• Usando Semantic-Release com Github Actions
• Workflow de release de outro projeto

Etapas do semantic-release:

Step	Description
Verify Conditions	Verify all the conditions to proceed with the release.
Get last release	Obtain the commit corresponding to the last release by analyzing Git tags.
Analyze commits	Determine the type of release based on the commits added since the last release.
Verify release	Verify the release conformity.
Generate notes	Generate release notes for the commits added since the last release.
Create Git tag	Create a Git tag corresponding to the new release version.
Prepare	Prepare the release.
Publish	Publish the release.
Notify	Notify of new releases or errors.

PRÉ-REQUISITO

Somente implementar entrega contínua com os testes de API finalizados. Está sendo tratado na issue #1.

Implement CI - GitHub Actions

Token de autenticação é lido como válido em sessões diferentes

Descrição do bug

Ao gerar um token de autenticação com duração longa (5 minutos) e reiniciar o ServeRest, o token permanece sendo utilizável.

Comportamento esperado

Que o token seja válido apenas para a sessão existente. Ao reiniciar o ServeRest ele deve ser considerado inváido.

Descrição técnica

A chave utilizada para gerar o token de autenticação está fixo.
https://github.com/PauloGoncalvesBH/ServeRest/blob/90dfff4458af725aa0bf582ee1846ad119c310bc/src/services/auth-service.js#L7
Substituir essa chave pelo v4 fornecido pelo uuid. Dessa forma será randômico, por sessão.

Subir serverest em background via terminal

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Nâo considero um problema.
Acredito que seja apenas uma futura feature para melhorar ainda mais o serverest.

Hoje, com o comando npx serverest, nosso terminal acaba por se "ocupar" até que o servidor seja parado, então, acaba por ser necessário a abertura de outro terminal e/ou aba. Para uma maior facilidade e até rapidez, subir o servidor em background via terminal seria uma ótima solução.

Descreva a solução que você deseja
A solução seria criarmos um argumento que fizesse o servidor subir em background via terminal.

Descreva as alternativas que você considerou
O webdriver-manager possui exatamente essa funcionalidade que pode ser vista AQUI

Podemos observar a opção: webdriver-manager start --detach

Contexto adicional
Acredito que poderiamos criar essa opção para os usuários e não mais travarmos o terminal ao subirmos o server.

Implement API documentation, like swagger UI

Mover a documentação do apiary para o swagger UI

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.

1. A documentação atual não é tão clara e sucinta igual uma gerada no swagger UI.
2. Não é possível o usuário consumir as APIs de forma amigável, pois não há campo para realizar as requests.
3. Outro problema é de que para edição da doc atual é preciso fornecer acesso à ferramenta apiary, o que é inviável. Com swagger qualquer usuário conseguirá editar a documentação.

Descreva a solução que você deseja
Refazer toda a documentação utilizando swagger UI

Incluir maximilianoalves como colaborador

O Max apresentou o ServeRest na sua talk sobre testes de API com Cypress.

Erro 'entity.parse.failed' ao usar CURL

Descreva o bug
Ao realizar a seguinte request:
curl --request POST --header "Content-Type: application/json" --data "{'nome':'Lucas Amaral', 'email':'[email protected]', 'password':'123457', 'administrador':'false'}" http://localhost:3500/usuarios

É retornado o seguinte erro:
{"error":{"expose":true,"statusCode":400,"status":400,"body":"{'nome':'Lucas Amaral', 'email':'[email protected]', 'password':'123457', 'administrador':'false'}","type":"entity.parse.failed"}}

Comportamento esperado
O POST seja feito corretamente ou a mensagem auxilie na solução do problema.

Cobertura de código

Incluir métricas de cobertura de código.

Criar badge do ServeRest

Inserir no README.md informação sobre badge do ServeRest, contendo sugestão para as pessoas incluírem em seus projetos.

Acredito que o melhor local é antes da seção 'Empresas que utilizam o ServeRest', mas fica a seu critério essa implementação.(Podemos discutir sobre na PR)

O texto deve estar em português e deve ter o a badge em si e o código da badge em markdown para o usuário copiar. (é assim nos 2 exemplos abaixo)

Projetos que pode usar de inspiração:

1. commitizen
2. Standard

Sugestão de página para gerar a badge:
img.shields

Implementar monitoramento

Ainda necessita de estudos e encontrar ferramenta que sirva a esse propósito.
Implementar monitoramento para entender o comportamento dos usuários.
Exemplo: saber quais rotas os usuários mais consomem, status Code que mais ocorre, ferramenta mais utilizada para chamar o ServeRest (a partir da info no header).

Implementar testes de regressão

Após o deploy em serverest.dev e da publicação de novas versões no NPM e Docker (seja @beta ou @latest), é preciso executar os testes de regressão pra validar se o comportamento do ServeRest está como esperado.

1. Taguear alguns dos testes como @regressao.
2. Executar os testes na pipeline de entrega contínua.
   1. Teste no NPM e Docker serão executados na etapa release. https://github.com/PauloGoncalvesBH/ServeRest/blob/3559189167669da148e9de396834515407df1168/.github/workflows/continuous_delivery.yml#L58
   2. Teste no serverest.dev será executado na etapa release-on-serverest-dev. https://github.com/PauloGoncalvesBH/ServeRest/blob/3559189167669da148e9de396834515407df1168/.github/workflows/continuous_delivery.yml#L80
   3. Teste no Docker será direcionado para a tag @latest e no NPM será direcionado para @beta ou @latest de acordo com a branch atual. Ver mais aqui

Docker publica as versões da branch beta e trunk sempre como tag @latest. Isso é uma limitação do semantic-release de docker.

Mensagem de campo vazio está em inglês

Descreva o bug
A mensagem de erro de campo vazio não está traduzido igual as outras mensagens.

Reproduzir
Enviar POST em /login com o seguinte corpo:

{
  password: "senha"
  email: ""
}

O retorno será o seguinte:

{
  email:""email" is not allowed to be empty"
}

Comportamento esperado
A mensagem deve ser traduzida para algo como email não pode estar em branco.

Contexto:
Versão do ServeRest: 2.9.0

Descrição técnica

Ajuste deve ser feito no arquivo montarMensagemDeErroDeSchema.js e novo teste de API deve ser criado para garantir cobertura.

Implement mongoDB instead json file

Refatoração total

Refatoração total seguindo os seguintes itens:

• Uso do express para request
• Uso de morgan para log
• Uso de nedb para manipulação dos arquivos
• Uso de celebrate para validação do body. (#5)

Essas alterações vão:

1. Reduzir a quantidade de dependências.
2. Possibilitar implementação do swagger.
3. Permitir organização correta da estrutura. Ler Bulletproof node.js project architecture.
4. Remover o uso da dependência request, que foi descontinuada.

Implementar stub nos testes

Muitos testes podem ter trechos substituídos por stubs, reduzindo a quantidade de requests e dependências.
Implementação está sendo feita na branch stub-test.

Disponibilizar no docker hub

Disponibilizar o ServeRest no docker hub.

Estando no docker hub será possível que usuários tenham 2 formas de utilizar o serverest, sem serem obrigados instalarem node.

• Incluir informação de uso com docker no README.md
• OPCIONAL: Incluir na entrega contínua o build e disponibilização no docker hub. Pré-requisito do job será criação de release.
  • https://github.com/felixfbecker/semantic-release-docker
  • Sobre esse ponto me chame se tiver qualquer dúvida, podemos até fazer uma videochamada.

Documentação:

• Revisar documentação do CONTRIBUTING.md
• Revisar Dockerfile
• Revisar MAKEFILE

Rodar os testes em várias versões do Node

Os testes das pipelines de entrega contínua e integração contínua são executadas apenas na última versão do Node disponibilizada pela action setup-node.

Para garantir que o ServeRest suporta todas as versões LTS do Node, é preciso que ele execute nas versões 10, 12 e 14.

Isso é possível utilizando matrix.

Material de apoio:

• Example running with more than one version of Node.js
• actions/setup-node

Arquivos que serão alterados:

• continuous_delivery.yml
• continuous_integration.yml

Erro ao acessar http://localhost:3000/ com Docker

Estou testando o ServeRest com Docker, e ao acessar http://localhost:3000/ no navegador, recebo a seguinte mensagem:

{
    "message": "Abra uma issue informando essa resposta. https://github.com/PauloGoncalvesBH/ServeRest/issues",
    "error": {
        "errno": -2,
        "code": "ENOENT",
        "syscall": "stat",
        "path": "/usr/src/app/docs/localhost.html",
        "expose": false,
        "statusCode": 404,
        "status": 404
    }
}

Mover arquivos relacionados à documentação

@PauloGoncalvesBH what about moving the CHANGELOG.md, CODE_OF_CONDUCT.md and CONTRIBUTING.md to the .github folder since it's related to the project documentation or setting the visibility of Wiki page?

Originally posted by @leandromuto in #54 (comment)

Achei muito boa a sugestão do @leandromuto sobre mover arquivos relacionados à documentado para o diretírio .github ou para a Wiki (que está desabilitada).

Porém não sei qual seria a melhor opção, e com isso gostaria de iniciar aqui uma discussão.

O único ponto que penso é que deixando no repositório, dentro de .github, ao invés de mover para a wiki, mantém tudo versionado.

alguns workflows não estão rodando em PR de terceiros

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Um usuário abriu determinado pull request e apenas o workflow continuous_integration.yml foi executado, enquanto os outros, de teste de mutação, check-links e codeql, não foram executados.

Com isso a qualidade do PR não está sendo garantida.

Descreva a solução que você deseja
Alterar os seguintes workflows para rodarem em pull_request:

1. check-link
2. codeql
3. mutation test

Descreva as alternativas que você considerou
Na seção on: desses arquivos inserir a tag pull_request:. Dessa forma esses workflows rodarão em PR.

Utilize a linha 4 do workflow de integração contínua como inspiração caso esteja com dúvidas: https://github.com/PauloGoncalvesBH/ServeRest/blob/trunk/.github/workflows/continuous_integration.yml

https://github.com/PauloGoncalvesBH/ServeRest/blob/1f9f6339d2cd00a81804c64e0a1d2b463b677f90/.github/workflows/continuous_integration.yml#L4

Implementar GraphQL

Será criado nova rota utilizando GraphQL.
Assim que possuir mais detalhes serão inseridos aqui.

Reconhecer todos que contribuíram

Esas issue é basicamente para utilizar o bot do all-contributors e reconhecer todos que colaboraram com o ServeRest.

Implementar error handler

Uso da lib https://www.npmjs.com/package/express-async-errors

Está sendo implementado pelo @gabriel-pinheiro

Create test

Melhorias nas mensagens defaults

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Nâo considero um problema.
Acredito que seja apenas uma futura feature para melhorar ainda mais o serverest.

Hoje, através de uma possível lib, temos a resposta default do tipo:

{
  "error": {
    "name": "ValidationError",
    "message": "Validation Failed",
    "statusCode": 400,
    "error": "Bad Request",
    "details": [
      {
        "email": "\"email\" is not allowed to be empty",
        "password": "\"password\" is not allowed to be empty"
      }
    ]
  }
}

Descreva a solução que você deseja
A solução seria padronizar as mensagens de erro.

Como podemos ver, as mensagens de erro aparecem no padrão em EN. Seria interessante além de personalizar as mensagens para PT-BR, elas fossem mais claras para os usuários, por exemplo:

{
    "email": "Email é obrigatório",
    "password": "Password é obrigatório"
}

Contexto adicional
Segue response de /login sem enviarmos um email e um password:

Falta aspas no json de autenticação na documentação

** Falta aspas no json de autenticacao **
Na documentação do projeto, o json de autenticação esta faltando aspas na cabeçalho do atributo.

Reproduzir
Etapas para reproduzir o comportamento:

1. Abrir documentação
2. e ir no item "Passando o seguinte corpo:"

pois esta:

{
  email: "[email protected]",
  password: "paulo"
}

para funcionar no meu foi necessário por aspas. conforme abaixo:

{
  "email": "[email protected]",
  "password": "paulo"
}

Criar template de pull request

Criar template de pull request

O template de Pull Request servirá de apoio para novos colaboradores conseguirem entregar código de qualidade e adequado para o projeto.

Inspirações:

• protractor-helper
• mocha

Internationalize ServeRest

Internationalize ServeRest

Internationalization will make it possible to increase the number of contributors and users.

Being in Portuguese it is already having 200 daily downloads, with the internationalization the number of downloads should increase considerably.

Besides, there is no project in English that provides REST server in an easy way as the serverest containing the main verbs and settings.

It is necessary to translate all tests, routes, schemas, functions, variables, documentation, help and response of the routes.

Implementar badge - Semantic release

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Uma descrição clara e concisa de qual é o problema. Ex. Fico sempre frustrado quando [...]

Descreva a solução que você deseja
Uma descrição clara e concisa do que você deseja que aconteça.

Descreva as alternativas que você considerou
Uma descrição clara e concisa de qualquer solução ou recurso alternativo que você tenha considerado.

Contexto adicional
Adicione qualquer outro contexto ou captura de tela sobre a solicitação de recurso aqui.

Traduzir mensagem 'must be of type object'

Descreva o bug
A mensagem de erro de que propriedade deve ser objeto não está traduzido igual as outras mensagens.

Reproduzir
Enviar POST em /carrinhos com o seguinte corpo:

[
  null
]

O retorno será o seguinte:

{
  "value": "\"value\" must be of type object"
}

Comportamento esperado
A mensagem deve ser traduzida para algo como X deve ser objeto.

Contexto:
Versão do ServeRest: 2.9.2

Descrição técnica

Ajuste deve ser feito no arquivo montarMensagemDeErroDeSchema.js e novo teste de API deve ser criado para garantir cobertura.

Executar teste de mutação apenas para arquivos alterados

Agora ao invés de rodar teste de mutação para todos os arquivos, o que demora aproximadamente 19 minutos, irá rodar apenas nos arquivos JS em /src que foram alterados na branch do PR. Com isso a execução será muito mais rápida e vai possibilitar que faça parte da pipeline de entrega contínua.

Essa issue já está em andamento no PR #172
Será utilizada a lib stryker-diff-runner.

Cross-origin resource sharing não liberado

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Quando criei uma aplicação react e axios, E quando tento me conectar com a sua api acontece o erro de cors, devido não estar liberado, assim não é possível se comunicar localmente pela url http://localhost:3000/qualquer_rota.

Descreva a solução que você deseja
Apenas instalar o pacote "cors": "^2.8.5"
e adicionar o seguinte comando no arquivo app.js

const cors = require('cors');
app.use(cors());

Assim quem tem um client consegue se comunicar com a sua api.

Incluir logo de empresas na documentação

Adicionar na seção de empresas que utilizam o ServeRest, no README, a logo das empresas:

1. Trybe (Escola de programação)
2. AILOS - Sistema de cooperativas de crédito
3. Ânima Educação

Não executar log no ambiente de desenvolvimento

Log da lib Morgan.
Utilizar variável de ambiente para saber se está em produção ou testes.
Isso vai tornar o resultado dos testes mais limpo.

Implementar testes de mutação

Dica de uso: stryke mutation

https://stryker-mutator.io/stryker/quickstart

Publish API on free page

Need analysis where to post.
GitHub Page? Heroku?

Attention; Deploy need to be a step on CI. #2

Adequação à LGPD

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
O ServeRest não está adequado à LGPD, embora não use os dados coletados para fins de ganhos financeiros.

Descreva a solução que você deseja
Precisamos informar aos usuários logo após a execução do ServeRest de que coletamos o nome de usuário da máquina da pessoa para entendermos o uso que ela faz e fazer os ajustes necessários (correção de bug e criação de novas features).

Precisamos informar que:

1. Coletamos o nome da máquina da pessoa.
2. Coletamos TODOS os dados das requests feitas, como: Headers, body, response, status code, user agent e versão do ServeRest.
3. A pessoa pode solicitar todos os dados coletados dela e o mais breve possível será enviado link para ela com todas as informações. Para isso a pessoa precisará abrir issue informando nome de usuário da máquina dela.
4. A pessoa pode solicitar que o perfil dela seja excluído, mantendo todos os dados anônimos.
5. A pessoa pode solicitar que o perfil e todos os dados coletados dela sejam excluídos.
6. Que esses dados são importantes para a manutenção do ServeRest, já tendo revelado bugs em produção.

Print mostrando os dados de usuários coletados:

Código do ServeRest que coleta o nome de usuário da máquina:
https://github.com/PauloGoncalvesBH/ServeRest/blob/6d040e6fa0dcb876a8d3b440122d128b79f48805/src/monitor.js#L19

Descreva as alternativas que você considerou

1. Colocar no README sobre essa coleta, criando a seção LGPD.
2. Criar template de issue chamado LGPD, facilitando a solicitação de exclusão dos dados ou repasse dos dados.
3. No terminal logo após a execução do ServeRest informar que alguns dados são coletados, e que para se informar mais ler a seção LGPD no README. (Ainda sem certeza de se a mensagem será exibida logo após o início do ServeRest ou na seção de help npx serverest -h) Para essa implementação será preciso verificar se está sendo utilizado docker ou npm para rodar.

Contexto adicional

• A ferramenta utilizada é a moesif.com.
• Essa coleta de nome de usuário é feita exclusivamente quando utiliza o ServeRest via npx. Ao utilizar com docker os dados são enviados de forma anônima.

Executar os testes de API no pré-push

Descreva a solução que você deseja
Os testes de API são executados apenas na integração e entrega contínua nas Actions do GitHub.
Para garantir qualidade e velocidade é interessante que os testes sejam executados no pré-push, abortando o commit caso os testes e a cobertura de código (executado automaticamente após os testes de API) falhem.

Descreva as alternativas que você considerou
No arquivo package.json, dentro de husky (linha 34), incluir a hooks pre-push com o comando npm test.

Para saber mais do husky, acesse a página do projeto.

Contexto adicional
Além de adicionar o pre-push no hooks do husky, é importante:

• Alterar o arquivo CONTRIBUTING.md
  • Inserir na seção Testes de API o ícone de que a validação é executada localmente (ícone de notebook)
  • Inserir o mesmo ícone acima no sumário
  • Alterar na seção Legenda o texto do ícone de notebook para Validação realizada localmente
  • Inserir texto no Testes de API de que commit será abortado. Seguir exemplo da seção de Lint e Commit
  • Mudar a seção Cobertura de código para ser uma subseção da seção de testes de API e remover os ícones dela.
  • Ao mudar a seção de cobertura de código, corrigir o sumário para que ela esteja como filha da seção testes de API.

Adicionar imagens dos produtos

Solicitação de recurso.
Comecei a fazer um front para a pi e senti falta de foto dos produtos ao criar a lista de produtos.

Solução
Seria legal adicionar o parâmetro de foto do produto, quem usar isso pra front fica melhor visualmente.

Documentar todo o processo de desenvolvimento

• Adicionar o conteúdo do post "Entrega contínua no ServeRest" no contributing.md: https://github.com/PauloGoncalvesBH/entrega-continua-no-serverest
• Detalhar a questão de que a branch beta gera nova versão com a dist-tag beta.
• Detalhar o conteúdo do changelog (o conteúdo do post esta desatualizado)
• Detalhar bot do codecov

Procurar o máximo de detalhamento possível para o projeto poder ser 100% independente.

Código de retorno errado quando o método não é suportado pelo recurso

** Descreva o bug **
Código de retorno errado quando o método não é suportado pelo recurso. O código está 404, quando deveria ser 405 - Method not Allowed

referencias:
https://tools.ietf.org/html/rfc7231#section-6.5.5
https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Status/405

Reproduzir
Etapas para reproduzir o comportamento:

1. Enviar DELETE para um Produto
2. Ver o erro

Comportamento esperado
deve retornar 405

** Capturas de tela **
Se aplicável, adicione capturas de tela para ajudar a explicar seu problema.

** Contexto (preencha as seguintes informações): **

** Contexto adicional **

Erro 500 - Rota de produtos com a nova propriedade /imagem

Descreva o bug
No monitoramento do moesif surgiu erro 500 na rota de /produtos. E pelos detalhes da request o usuário utilizou a nova propriedade /imagem (incluído no PR #134) da rota POST /produtos com o Postman.

Reproduzir
Acessar o Postman v7.26.5 e realizar POST em /produtos com o seguinte body:

{
  "preco": "18",
  "imagem": "nada",
  "nome": "Produto Novo 2",
  "quantidade": "1",
  "descricao": "descrição produto novo"
}

É preciso autenticar em /login

Response:

{
  "message": "Abra uma issue informando essa resposta. https://github.com/PauloGoncalvesBH/ServeRest/issues",
  "error": {}
}

Comportamento esperado
O cadastro deveria ter retorno 400 ou 201.

Capturas de tela

Print do moesif com os detalhes da request:

Detalhe do user agent:

Contexto:

• Versão do ServeRest: 2.13.2
• O usuário levantou o ServeRest utilizando npx serverest, e não docker.

Alterar timeout de token de 1 segundo para 10 min

Alterar timeout de token de 1 segundo para 10 min.

Não há ganhos em timeout tão baixo. Isso acaba dificultando iniciantes em testes de API.

Incluir Bruno Batista como contributor

@all-contributors please add @brunobatista25 for ideas

Implement request body validation

teste - ajustar release

Migrar para typescript

Necessita de refinamento.

Opção de debug

Opção de debug para que o usuário consiga visualizar os dados da request que chegaram no ServeRest, como header, e body.

Esses dados serão impressos no console.

Para utilizar basta passar -D ou --debug.

Adicionar execução via Docker

Sua solicitação de recurso está relacionada a um problema? Por favor descreva.
Não!

Descreva a solução que você deseja
Seria legal a inicialização do projeto via docker, ja com uma imagem docker do docker hub, evitando conflitos de versionamento do computadores locais.