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.
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.