CRUD de Usuário NodeJS e TypeScript

Endpoints

Método	Endpoint	Responsabilidade
POST	/users	Cadastrar um novo usuário
POST	/login	Logar com um usuário na aplicação gerando um token.
GET	/users	Listar todos os usuários da aplicação
GET	/users/profile	Listar um usuário que está logado na aplicação
PATCH	/users/:id	Atualizar os dados de um usuário
DELETE	/users/:id	Fazer um soft delete de um usuário
PUT	users/:id/recover	Reativar um usuário

Nome da tabela: users
Colunas:
- id: inteiro, sequencial e chave primária.
- name: string, tamanho máximo de 20 e obrigatório.
- email: string, tamanho máximo de 100, único e obrigatório.
- password: string, tamanho máximo de 120 e obrigatório..
- admin: booleano, obrigatório e falso por padrão.
- active: booleano, obrigatório e verdadeiro por padrão

Nas rotas POST e PATCH, é necessário serializar os dados de entrada utilizando o zod;
- Chaves incorretas devem ser ignoradas caso enviadas.
Na rota POST /users as chaves de name, email e password são obrigatórias.
Na rota POST /users, as chaves id e active não devem ser enviadas e devem ser ignoradas pelo zod.;
- Esses dados devem ser gerados de forma automática pela aplicação.
Na rota POST /users a chave de admin é opcional.
- Caso não enviado, o dado será gerado de maneira automática pelo banco.
Na rota PATCH /users, as chaves id, admin e active não podem ser atualizadas.
- Caso sejam enviadas devem ser ignoradas;
A senha não deve ser retornada em nenhuma das rotas do serviço;

POST /users e PATCH /users

O email deve ser único:
- Caso seja enviado um email já registrado o retorno deve ser exatamente o abaixo:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 409 CONFLICT
```
{
    "message": "E-mail already registered"
}
```

Todas as rotas de POST e PATCH

Deve haver serialização de dados:
- A serialização dos dados de entrada deve ser feita utilizando o zod.
- Em caso de erro a mensagem retornada deve seguir o padrão a seguir:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 400 BAD REQUEST
```
{
    "name": ["Required"],
    "email": ["Invalid email"],
    "password": ["Expected string, received number"]
}
```

GET /users, PATCH /users, DELETE /users e PUT /users

Devem conter validação por token:
- Caso o token não seja enviado, deve se obter o seguinte retorno:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 401 UNAUTHORIZED
```
{
    "message": "Missing Bearer Token"
}
```
- Caso haja um erro na decodificação do token JWT, deve-se retornar a mensagem de erro padrão da biblioteca, nos parâmetros abaixo:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 401 UNAUTHORIZED
```
{
  "message": // mensagem padrão da biblioteca
}
```

GET /users e PUT /users/:id/recover

Apenas administradores podem acessar:
- Caso um usuário não administrador faça requisição, deve-se obter o seguinte retorno:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 403 FORBIDDEN
```
{
    "message": "Insufficient Permission"
}
```

PATCH /users/:id e DELETE /users/:id

Tanto usuários administradores quanto não administradores podem fazer requisições:
- Um usuário não administrador só pode atualizar ou deletar a sí mesmo;
- Um usuário administrador pode atualizar ou deletar qualquer usuário;
- Caso um usuário não administrador tente deletar ou atualizar outro usuário que não seja o dele, deve-se obter o seguinte retorno:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 403 FORBIDDEN
```
{
    "message": "Insufficient Permission"
}
```

POST /login

Deve validar se o usuário:
- Existe (email valido);
- Está ativo;
- Se a senha está correta.
- Caso não passe em alguma das validações anteriores deve-se obter o seguinte retorno:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 401 UNAUTHORIZED
```
{
    "message": "Wrong email/password"
}
```

PUT /users/:id/recover

Deve reativar um usuário que está inativo:
- O valor de active deve ser alterado para true;
- Caso o active do usuário com o id enviado na rota já seja true, deve-se retornar o seguinte:
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 400 BAD REQUEST
```
{
    "message": "User already active"
}
```

Todas as rotas que recebem id por parâmetro

Deve verificar se o id passado existe:
Caso o usuário do id passado não exista deverá retornar o seguinte:

Resposta do servidor:

Body: Formato Json

Status code: 404 NOT FOUND
```
{
    "message": "User not found"
}
```

Exemplos de Requisição

Rotas não autenticadas

Essas rotas não precisam de um token válido para serem acessadas.

POST /users

Rota de criação de usuário. A chave admin é opcional, caso não enviada deve ser definida como false.

Dados de Envio:
Body: Formato Json

{
    "name": "Joao",
    "email": "joao@joao.com.br",
    "password": "naomaisjoao",
    "admin": true,
    "active": false
}

Resposta do servidor:
Body: Formato Json
Status code: 201 CREATED

// atente-se ao valor de active recebido e retornado;
{
    "id": 1,
    "name": "Joao",
    "email": "joao@joao.com.br",
    "admin": true,
    "active": true
}

POST - /login
- Deve ser capaz de gerar um token jwt válido.
  
  Dados de Envio:
  
  Body: Formato Json
```
{
    "email": "joao@joao.com.br",
    "password": "naomaisjoao"
}
```
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 200 OK
```
{
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}
```

Rotas autenticadas

Todas as rotas a seguir devem ser autenticas.

No header(cabeçalho) da requisição deve ser enviado um Bearer <token>.

Header
Option: Authorization
Type: Bearer
Value: JWT token

{
    "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI..."
}

GET - /users

Rota de listagem de usuários;

Deve retornar todos os usuários da aplicação.

Resposta do servidor:
Body: Formato Json
Status code: 200 OK

[
    {
        "id": 1,
        "name": "Joao",
        "email": "joao@joao.com.br",
        "admin": true,
        "active": true
    },
    {
        "id": 2,
        "name": "Gabriel",
        "email": "gabriel@gabriel.com.br",
        "admin": false,
        "active": false
    }
]

GET - /users/profile
- Rota de perfil. Deve retornar todos os dados dos usuário logado.
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 200 OK
```
{
    "id": 1,
    "name": "Joao",
    "email": "joao@joao.com.br",
    "admin": true,
    "active": true
}
```
PATCH - /users/:id
- Rota de atualização de usuário. Deve ser capaz de atualizar tanto um quanto todos os dados de um usuário.
- O exemplo abaixo foi feito na rota /users/1.
  
  Dados de Envio:
  
  Body: Formato Json
```
{
    "name": "Joao"
}
```
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 200 OK
```
{
    "id": 1,
    "name": "Joao",
    "email": "joao@kenzie.com.br",
    "admin": true,
    "active": true
}
```

DELETE - /users/:id

Deve ser capaz de fazer soft delete em um usuário;

O soft delete é a ação de modificar alguma propriedade de uma tabela que indica que o dado está ativo ou não, nesse caso é a propriedade active da tabela de users, na qual é possível identificar que o mesmo foi "marcado" como deletado, mas suas informações ainda irão permanecer no banco. Sendo uma modificação em vez deleção.

O exemplo abaixo foi feito na rota /users/2

Resposta do servidor:

Body: Nenhum

Status code: 204 NO CONTENT
```
  // nenhum dado deve ser retorando
```

PUT - /users/:id/recover
- Deve ser capaz de recuperar o usuário que foi desativado.
- O active deve ser alterado para true.
- O exemplo abaixo foi feito na rota /users/2/recover.
  
  Resposta do servidor:
  
  Body: Formato Json
  
  Status code: 200 OK
```
{
    "id": 2,
    "name": "Gabriel",
    "email": "gabriel@gabriel.com.br",
    "admin": false,
    "active": true
}
```

jooaogbriel/teste-NodeJS