Issue 4: Criação de usuários

[lhps]

• [ ] Criar migration para criar a tabela users
• [ ] Criar model para encapsular métodos de criação e alteração de usuários
• [ ] Criar controller com rotas que executarão os métodos definidos na model
• [ ] Criar rota POST /api/v1/users para criar usuários
• [ ] Criar rota GET /api/v1/users/{username} para consultar um usuário
• [ ] Ao consultar um usuário especifico será retornado todos os campos dele, inclusive os privados (email, senha e etc)
• [ ] Criar usuários
• [ ] Ler usuários
• [ ] Atualizar usuários
• [ ] Garantir que os testes executem com sucesso nos endpoints, fazer de alguma forma as migrations serem executadas para a tabela de users existir no momento dos testes serem executados

obs: As senhas não serão salvar como hash e sim como texto puro no banco de dados.

[lhps]

Contexto Ser possível Criar, Ler e Atualizar um usuário no sistema, inicialmente sem nenhum sistema de Autenticação nem Autorização. Vamos começar da forma mais simples possível para ir sofisticando aos poucos e ir entendendo o motivo de cada sofisticação existir.

Execução Para isto ser possível, será necessário:

Migration: uma que crie a tabela users no sistema. Model: um que encapsule os comandos de criação do usuário e que vai poder ser reutilizado em qualquer contexto. Controller: para que seja possível receber a conexão que veio através da Rota e ela utilizar o model para executar os comandos. Rota: uma rota pública /api/v1/users para criar users e outra /api/v1/users/[username] para consultar um usuário em específico. Não será necessário listar os usuários cadastrados no sistema. Atenção Não é necessário o comando de Deletar um usuário. Não é necessário criar o hash do campo password e vamos cometer o crime de salvar em texto puro, para que na issue sobre Autenticação para nunca mais ninguém cometer este crime. No retorno público da API ao consultar um user, vamos retornar todos os campos, inclusive os privados como email e password, para quando entrarmos na issue sobre Autorização ser possível definir um filtro de saída. Inclusive, não é preciso fazer nenhum tipo de validação dos campos nesta primeira versão. Para testar com sucesso o novo endpoint de usuários, é necessário que o Banco de Dados esteja com as migrações rodadas e hoje o orchestrator não faz isso, ele apenas limpa os dados (ao recriar o schema). Os detalhes de implementação que rodam as migrations estão implementadas diretamente dentro do controller do endpoint /api/v1/migrations. Vamos precisar abstrair para outro lugar (um model) para reutilizar esta lógica.