Boas-vindas ao repositório do projeto API de Blogs!

👨‍💻 O que deverá ser desenvolvido

Neste projeto você vai desenvolver uma API e um banco de dados para a produção de conteúdo para um blog!

Você deverá desenvolver uma aplicação em Node.js usando o pacote sequelize para fazer um CRUD de posts.

Você deverá desenvolver endpoints que estarão conectados ao seu banco de dados seguindo os princípios do REST;
Para fazer um post é necessário usuário e login, portanto será trabalhada a relação entre user e post;
Será necessária a utilização de categorias para os posts, trabalhando, assim, a relação de posts para categories e de categories para posts.

‼️ Antes de começar a desenvolver

Clone o repositório

git clone git@github.com:FranciscoVieir/Project-blogs-api.git.
Entre na pasta do repositório que você acabou de clonar:
- cd project-blogs-api

Instale as dependências [Caso existam]

npm install

Desafios

1 - Crie migrations para as tabelas `users`, `categories`, `blog_posts`, `posts_categories`

Esse teste fará uma conexão no banco utilizando a configuração de teste do arquivo src/config/config.js;
Suas migrations devem estar no diretório correto e respeitar a nomenclatura pedida no requisito;
Suas migrations devem respeitar o diagrama de Entidade-Relacionamento e o formato das entidades, como descrito na seção de Diagrama ER e Entidades.
Todas as tabelas e colunas devem estar em snake_case

Os seguintes pontos serão avaliados:

[Será validado que é possível fazer um INSERT e um SELECT na tabela users]
- O avaliador irá inserir um dado de exemplo na tabela users;
- O avaliador irá fazer um select, desse mesmo dado, na tabela users.
[Será validado que é possível fazer um INSERT e um SELECT na tabela categories]
- O avaliador irá inserir um dado de exemplo na tabela categories;
- O avaliador irá fazer um select, desse mesmo dado, na tabela categories.
[Será validado que, a partir de um INSERT em users, é possível fazer um INSERT e um SELECT na tabela blog_posts]
- Dado que blog_posts possui uma chave estrangeira user_id:
  - O avaliador irá inserir um dado de exemplo na tabela users;
- Desse modo:
  - O avaliador irá inserir um dado de exemplo na tabela blog_posts;
  - O avaliador irá fazer um select, desse mesmo dado, na tabela blog_posts.
[Será validado que, a partir de INSERTs em users, categories e blog_posts, é possível fazer um INSERT e um SELECT na tabela posts_categories]
- Dado que posts_categories possui uma chave primária composta de duas chaves estrangeiras, respectivamente, post_id, category_id:
  - O avaliador irá inserir um dado de exemplo na tabela users;
  - O avaliador irá inserir um dado de exemplo na tabela categories;
  - O avaliador irá inserir um dado de exemplo na tabela blog_posts;
- Desse modo:
  - O avaliador irá inserir um dado de exemplo na tabela posts_categories;
  - O avaliador irá fazer um select, desse mesmo dado, na tabela posts_categories.

2 - Crie o modelo `User` em `src/models/User.js` com as propriedades corretas

Sua model deve estar no diretório correto e respeitar a nomenclatura pedida no requisito;
Sua model deve respeitar o diagrama de Entidade-Relacionamento e o formato das entidades, como descrito na seção de Diagrama ER e Entidades;
As propriedades podem estar em camelCase se underscored for true. Ou seja, quando os dados forem inseridos ou selecionados via model devem estar em camelCase, mas quando as queries forem pra o banco os campos das colunas devem estar em snake_case.
Sua model deve ser desenvolvida em formato funcional, ou seja, não pode ser uma classe.

Se você usa MacOS

Esse requisito pode dar um falso positivo! Garanta que o nome do arquivo está em PascalCase. O avaliador, que roda em Linux, é case-sensitive para arquivos, enquanto o MacOS, entre outros sistemas, são case-insensitive. Ou seja: na sua máquina pode rodar, e no avaliador não, então fique de olho! Caso queria se aprofundar nesse assunto, veja o seguinte link.

Os seguintes pontos serão avaliados:

[Será validado que existe o arquivo 'User.js']
[Será validado que o modelo possui o nome 'User']
[Será validado que o modelo possui a propriedade 'id']
[Será validado que o modelo possui a propriedade 'display_name']
[Será validado que o modelo possui a propriedade 'email']
[Será validado que o modelo possui a propriedade 'password']
[Será validado que o modelo possui a propriedade 'image']

3 - Sua aplicação deve ter o endpoint POST `/login`

O endpoint deve ser acessível através do URL /login;

O corpo da requisição deverá seguir o formato abaixo:

{
  "email": "lewishamilton@gmail.com",
  "password": "123456"
}

Os seguintes pontos serão avaliados:

[Será validado que não é possível fazer login sem todos os campos preenchidos]
- Se a requisição não tiver todos os campos devidamente preenchidos(não pode haver campos em branco), o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "Some required fields are missing"
}
```
[Será validado que não é possível fazer login com um usuário que não existe]
- Se a requisição receber um par de email e password errados/inexistentes, o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "Invalid fields"
}
```
[Será validado que é possível fazer login com sucesso]
- Se o login foi feito com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:
```
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXlsb2FkIjp7ImlkIjo1LCJkaXNwbGF5TmFtZSI6InVzdWFyaW8gZGUgdGVzdGUiLCJlbWFpbCI6InRlc3RlQGVtYWlsLmNvbSIsImltYWdlIjoibnVsbCJ9LCJpYXQiOjE2MjAyNDQxODcsImV4cCI6MTYyMDY3NjE4N30.Roc4byj6mYakYqd9LTCozU1hd9k_Vw5IWKGL4hcCVG8"
}
```
⚠️ O token anterior é fictício, seu token deve ser gerado a partir da variável de ambiente JWT_SECRET, do payload da requisição e não deve conter o atributo password em sua construção.

4 - Sua aplicação deve ter o endpoint POST `/user`

O endpoint deve ser acessível através do URL /user;
O endpoint deve ser capaz de adicionar um novo user a sua tabela no banco de dados;

O corpo da requisição deverá seguir o formato abaixo:

{
  "displayName": "Brett Wiltshire",
  "email": "brett@email.com",
  "password": "123456",
  "image": "http://4.bp.blogspot.com/_YA50adQ-7vQ/S1gfR_6ufpI/AAAAAAAAAAk/1ErJGgRWZDg/S45/brett.png"
  // a imagem não é obrigatória
}

Os seguintes pontos serão avaliados

[Será validado que não é possível cadastrar com o campo displayName menor que 8 caracteres]
- Se a requisição não tiver o campo displayName devidamente preenchido com 8 caracteres ou mais, o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "\"displayName\" length must be at least 8 characters long"
}
```
[Será validado que não é possível cadastrar com o campo email com formato inválido]
- Se a requisição não tiver o campo email devidamente preenchido com o formato <prefixo@dominio>, o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "\"email\" must be a valid email"
}
```
[Será validado que não é possível cadastrar com o campo password menor que 6 caracteres]
- Se a requisição não tiver o campo password devidamente preenchido com 6 caracteres ou mais, o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "\"password\" length must be at least 6 characters long"
}
```
[Será validado que não é possível cadastrar com um email já existente]
- Se a requisição enviar o campo email com um email que já existe, o resultado retornado deverá ser conforme exibido abaixo, com um status http 409:
```
{
  "message": "User already registered"
}
```
[Será validado que é possível cadastrar um pessoa usuária com sucesso]
- Se o user for criado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 201:
```
  {
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXlsb2FkIjp7ImlkIjo1LCJkaXNwbGF5TmFtZSI6InVzdWFyaW8gZGUgdGVzdGUiLCJlbWFpbCI6InRlc3RlQGVtYWlsLmNvbSIsImltYWdlIjoibnVsbCJ9LCJpYXQiOjE2MjAyNDQxODcsImV4cCI6MTYyMDY3NjE4N30.Roc4byj6mYakYqd9LTCozU1hd9k_Vw5IWKGL4hcCVG8"
  }
```
⚠️ O token anterior é fictício, seu token deve ser gerado a partir da variável de ambiente JWT_SECRET, do payload da requisição e não deve conter o atributo password em sua construção.

⚠️ Validando token nas requisições

Após termos feito o requisito de criação de users e o requisito de login, alguns requisitos abaixo vão precisar desta autenticação prévia, para que seja possível consumir o endpoint;
Todo requisito que precisar validar o token terá o símbolo ☝;
✨ Dica: Se é algo que vamos utilizar em mais de uma rota, será que podemos separa-lo em algum lugar que comece com M de middleware? 😜

Os seguintes pontos serão avaliados

[Será validado que não é possível fazer uma operação sem o token na requisição]
- Se o token for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:
```
{
  "message": "Token not found"
}
```
[Será validado que não é possível fazer uma operação com o token inválido]
- Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:
```
{
  "message": "Expired or invalid token"
}
```

5 - Sua aplicação deve ter o endpoint GET `/user`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /user;
O endpoint deve ser capaz de trazer todos users do banco de dados;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]

[Será validado que é possível listar todos os usuários]

Ao listar usuários com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

[
  {
      "id": 1,
      "displayName": "Lewis Hamilton",
      "email": "lewishamilton@gmail.com",
      "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
  },

  /* ... */
]

6 - Sua aplicação deve ter o endpoint GET `/user/:id`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /user/:id;
O endpoint deve ser capaz de trazer o user baseado no id do banco de dados se ele existir;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]

[Será validado que é possível listar um usuário específico com sucesso]

Ao listar um usuário com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

{
  "id": 1,
  "displayName": "Lewis Hamilton",
  "email": "lewishamilton@gmail.com",
  "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
}

[Será validado que não é possível listar um usuário inexistente]
- Se o usuário for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 404:
```
{
  "message": "User does not exist"
}
```

7 - Crie o modelo `Category` em `src/models/Category.js` com as propriedades corretas

Sua model deve estar no diretório correto e respeitar a nomenclatura pedida no requisito;
Sua model deve respeitar o diagrama de Entidade-Relacionamento e o formato das entidades, como descrito na seção de Diagrama ER e Entidades.
Sua model deve ser desenvolvida em formato funcional, ou seja, não pode ser uma classe.

Se você usa MacOS

Esse requisito pode dar um falso positivo! Garanta que o nome do arquivo está em PascalCase. O avaliador, que roda em Linux, é case-sensitive para arquivos, enquanto o MacOS, entre outros sistemas, são case-insensitive. Ou seja: na sua máquina pode rodar, e no avaliador não, então fique de olho! Caso queria se aprofundar nesse assunto, veja o seguinte link.

Os seguintes pontos serão avaliados

[Será validado que existe o arquivo 'Category.js']
[Será validado que o modelo possui o nome 'Category']
[Será validado que o modelo possui a propriedade 'id']
[Será validado que o modelo possui a propriedade 'name']

8 - Sua aplicação deve ter o endpoint POST `/categories`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /categories;
O endpoint deve ser capaz de adicionar uma nova categoria a sua tabela no banco de dados;
O corpo da requisição deverá seguir o formato abaixo:
```
{
  "name": "Typescript"
}
```

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]
[Será validado que não é possível cadastrar uma categoria sem o campo name]
- Se a requisição não tiver o campo name devidamente preenchidos(não pode haver campo em branco), o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "\"name\" is required"
}
```
[Será validado que é possível cadastrar uma categoria com sucesso]
- Se a categoria for criada com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 201:
```
{
  "id": 3,
  "name": "Typescript"
}
```

9 - Sua aplicação deve ter o endpoint GET `/categories`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /categories;
O endpoint deve ser capaz de trazer todas categorias do banco de dados;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]
[Será validado que é possível listar todas as categoria com sucesso]
- Ao listar categorias com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:
```
[
  {
      "id": 1,
      "name": "Inovação"
  },
  {
      "id": 2,
      "name": "Escola"
  },

  /* ... */
]
```

10 - Crie o modelo `BlogPost` em `src/models/BlogPost.js` com as propriedades e associações corretas

Sua model deve estar no diretório correto e respeitar a nomenclatura pedida no requisito;
Sua model deve respeitar o diagrama de Entidade-Relacionamento e o formato das entidades, como descrito na seção de Diagrama ER e Entidades;
Sua model deve respeitar a associação correta (N:1) com o modelo User;
As propriedades podem estar em camelCase se underscored for true. Ou seja, quando os dados forem inseridos ou selecionados via model devem estar em camelCase, mas quando as queries forem pra o banco os campos das colunas devem estar em snake_case.
Sua model deve ser desenvolvida em formato funcional, ou seja, não pode ser uma classe.
✨ Dica:
- Explore como renomear campos no Sequelize;

Se você usa MacOS

Esse requisito pode dar um falso positivo! Garanta que o nome do arquivo está em PascalCase. O avaliador, que roda em Linux, é case-sensitive para arquivos, enquanto o MacOS, entre outros sistemas, são case-insensitive. Ou seja: na sua máquina pode rodar, e no avaliador não, então fique de olho! Caso queria se aprofundar nesse assunto, veja o seguinte link.

Os seguintes pontos serão avaliados

[Será validado que existe o arquivo 'BlogPost.js']
[Será validado que o modelo possui o nome 'BlogPost']
[Será validado que o modelo possui a propriedade 'id']
[Será validado que o modelo possui a propriedade 'title']
[Será validado que o modelo possui a propriedade 'content']
[Será validado que o modelo possui a propriedade 'user_id']
[Será validado que o modelo possui a propriedade 'published']
[Será validado que o modelo possui a propriedade 'updated']
[Será validado que o modelo em 'BlogPost.js', define a associação 'belongsTo', com a entidade de nome 'User']
[Será validado que o modelo em 'User.js', define a associação 'hasMany', com a entidade de nome 'BlogPost']

11 - Crie o modelo `PostCategory` em `src/models/PostCategory.js` com as propriedades e associações corretas

Sua model deve estar no diretório correto e respeitar a nomenclatura pedida no requisito;
Sua model deve respeitar o diagrama de Entidade-Relacionamento e o formato das entidades, como descrito na seção de Diagrama ER e Entidades;
Sua model deve respeitar a associação correta (N:N) entre o modelo BlogPost e o modelo Category;
As propriedades podem estar em camelCase se underscored for true. Ou seja, quando os dados forem inseridos ou selecionados via model devem estar em camelCase, mas quando as queries forem pra o banco os campos das colunas devem estar em snake_case.
Sua model deve ser desenvolvida em formato funcional, ou seja, não pode ser uma classe.

Se você usa MacOS

Esse requisito pode dar um falso positivo! Garanta que o nome do arquivo está em PascalCase. O avaliador, que roda em Linux, é case-sensitive para arquivos, enquanto o MacOS, entre outros sistemas, são case-insensitive. Ou seja: na sua máquina pode rodar, e no avaliador não, então fique de olho! Caso queria se aprofundar nesse assunto, veja o seguinte link.

Os seguintes pontos serão avaliados

[Será validado que existe o arquivo 'PostCategory.js']
[Será validado que o modelo possui o nome 'PostCategory']
[Será validado que o modelo possui a propriedade 'post_id']
[Será validado que o modelo possui a propriedade 'category_id']
[Será validado que o modelo em 'PostCategory.js', através do(s) modelos(s) de nome(s) 'Category; BlogPost', define a associação 'belongsToMany' respectivamente, com o(s) modelo(s) de nome(s) 'BlogPost, Category']

12 - Sua aplicação deve ter o endpoint POST `/post`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /post;
O endpoint deve ser capaz de adicionar um novo blog post e vinculá-lo às categorias em suas tabelas no banco de dados;

O corpo da requisição deverá seguir o formato abaixo:

{
  "title": "Latest updates, August 1st",
  "content": "The whole text for the blog post goes here in this key",
  "categoryIds": [1, 2]
}

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]
[Será validado que não é possível cadastrar sem todos os campos preenchidos]
- Se a requisição não tiver todos os campos devidamente preenchidos(não pode haver campos em branco), o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "Some required fields are missing"
}
```
[Será validado que não é possível cadastrar um blog_post com uma categoryIds inexistente]
- Se a requisição não tiver o campo categoryIds devidamente preenchido com um array com todas as categorias existentes, o resultado retornado deverá ser conforme exibido abaixo, com um status http `400``:
```
{
  "message": "one or more \"categoryIds\" not found"
}
```
[Será validado que é possível cadastrar um blog_post com sucesso]

Se o blog post for criado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 201:

{
  "id": 3,
  "title": "Latest updates, August 1st",
  "content": "The whole text for the blog post goes here in this key",
  "userId": 1,
  "updated": "2022-05-18T18:00:01.196Z",
  "published": "2022-05-18T18:00:01.196Z"
}

13 - Sua aplicação deve ter o endpoint GET `/post`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /post;
O endpoint deve ser capaz de trazer todos os blogs post, user dono dele e as categorias do banco de dados;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]

[Será validado que é possível listar blogpost com sucesso]

Ao listar posts com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

[
  {
    "id": 1,
    "title": "Post do Ano",
    "content": "Melhor post do ano",
    "userId": 1,
    "published": "2011-08-01T19:58:00.000Z",
    "updated": "2011-08-01T19:58:51.000Z",
    "user": {
      "id": 1,
      "displayName": "Lewis Hamilton",
      "email": "lewishamilton@gmail.com",
      "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
    },
    "categories": [
      {
        "id": 1,
        "name": "Inovação"
      }
    ]
  },
  
  /* ... */
]

14 - Sua aplicação deve ter o endpoint GET `/post/:id`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /post/:id;
O endpoint deve ser capaz de trazer o blog post baseado no id do banco de dados se ele existir;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]

[Será validado que é possível listar um blogpost com sucesso]

Ao listar um post com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

{
  "id": 1,
  "title": "Post do Ano",
  "content": "Melhor post do ano",
  "userId": 1,
  "published": "2011-08-01T19:58:00.000Z",
  "updated": "2011-08-01T19:58:51.000Z",
  "user": {
      "id": 1,
      "displayName": "Lewis Hamilton",
      "email": "lewishamilton@gmail.com",
      "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
  },
  "categories": [
      {
          "id": 1,
          "name": "Inovação"
      }
  ]
}

[Será validado que não é possível listar um blogpost inexistente]
- Se o post for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 404:
```
{
  "message": "Post does not exist"
}
```

15 - Sua aplicação deve ter o endpoint PUT `/post/:id`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /post/:id;
O endpoint deve ser capaz de alterar um post do banco de dados, se ele existir;
Sua aplicação só deve permitir a alteração de um blog post caso a pessoa seja dona dele;
Sua aplicação não deve permitir a alteração das categorias do post, somente os atributos title e content podem ser alterados;

O corpo da requisição deverá seguir o formato abaixo:

{
  "title": "Latest updates, August 1st",
  "content": "The whole text for the blog post goes here in this key"
}

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]
[Será validado que não é possível editar um blogpost com outro usuário]
- Somente o user que criou o blog post poderá editá-lo, o resultado retornado deverá ser conforme exibido abaixo, com um status http 401
```
  {
    "message": "Unauthorized user"
  }
```
[Será validado que não é possível editar sem todos os campos preenchidos]
- Se a requisição não tiver todos os campos devidamente preenchidos(não pode haver campos em branco), o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:
```
{
  "message": "Some required fields are missing"
}
```

[Será validado que é possível editar um blogpost com sucesso]

Se o blog post for alterado com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

{
  "id": 3,
  "title": "Latest updates, August 1st",
  "content": "The whole text for the blog post goes here in this key",
  "userId": 1,
  "published": "2022-05-18T18:00:01.000Z",
  "updated": "2022-05-18T18:07:32.000Z",
  "user": {
    "id": 1,
    "displayName": "Lewis Hamilton",
    "email": "lewishamilton@gmail.com",
    "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
  },
  "categories": [
    {
      "id": 1,
      "name": "Inovação"
    },
    {
      "id": 2,
      "name": "Escola"
    }
  ]
}

Requisitos Bônus

16 - Sua aplicação deve ter o endpoint DELETE `/post/:id`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /post/:id;
O endpoint deve ser capaz de deletar um blog post baseado no id do banco de dados se ele existir;
Sua aplicação só deve permitir a deleção de um blog post caso a pessoa seja dona dele;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]
[Será validado que não é possível deletar um blogpost com outro usuário]
- Somente o user que criou o blog post poderá deletá-lo, o resultado retornado deverá ser conforme exibido abaixo, com um status http 401
```
  {
    "message": "Unauthorized user"
  }
```
[Será validado que é possível deletar um blogpost com sucesso]
- Se o blog post for deletado com sucesso não deve ser retornada nenhuma resposta, apenas um status http 204:
[Será validado que não é possível deletar um blogpost inexistente]
- Se o post for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 404:
```
{
  "message": "Post does not exist"
}
```

17 - Sua aplicação deve ter o endpoint DELETE `/user/me`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /user/me;
O endpoint deve ser capaz de deletar você do banco de dados, baseado no id que esta dentro do seu token;
Sua aplicação deve ser capaz de utilizar o token de autenticação nos headers, para saber o user logado correspondente á ser apagado;

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]
[Será validado que é possível excluir meu usuário com sucesso]
- Se o user for deletado com sucesso não deve ser retornada nenhuma resposta, apenas um status http 204:

18 - Sua aplicação deve ter o endpoint GET `/post/search?q=:searchTerm`

☝ Não esqueça de validar o token neste requisito, como descrito na seção de Validando token nas requisições;
O endpoint deve ser acessível através do URL /post/search;
O endpoint deve ser capaz de trazer os blogs post baseados no q do banco de dados, se ele existir;
Sua aplicação deve ser capaz de retornar um array de blogs post que contenham em seu título ou conteúdo o termo passado na URL;
Sua aplicação deve ser capaz de retornar um array vázio caso nenhum blog post satisfaça a busca;
O query params da requisição deverá seguir o formato abaixo:
```
  http://localhost:PORT/post/search?q=vamos
```

Os seguintes pontos serão avaliados

☝ [Será validado o token, como descrito na seção de Validando token nas requisições]

[Será validado que é possível buscar um blogpost pelo title]

Se a buscar for pelo title o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

// GET /post/search?q=Vamos que vamos

[
  {
    "id": 2,
    "title": "Vamos que vamos",
    "content": "Foguete não tem ré",
    "userId": 1,
    "published": "2011-08-01T19:58:00.000Z",
    "updated": "2011-08-01T19:58:51.000Z",
    "user": {
      "id": 1,
      "displayName": "Lewis Hamilton",
      "email": "lewishamilton@gmail.com",
      "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
    },
    "categories": [
      {
        "id": 2,
        "name": "Escola"
      }
    ]
  }
]

[Será validado que é possível buscar um blogpost pelo content]

Se a buscar for pelo content o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

  // GET /post/search?q=Foguete não tem ré

  [
    {
      "id": 2,
      "title": "Vamos que vamos",
      "content": "Foguete não tem ré",
      "userId": 1,
      "published": "2011-08-01T19:58:00.000Z",
      "updated": "2011-08-01T19:58:51.000Z",
      "user": {
        "id": 1,
        "displayName": "Lewis Hamilton",
        "email": "lewishamilton@gmail.com",
        "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
      },
      "categories": [
        {
          "id": 2,
          "name": "Escola"
        }
      ]
    }
  ]

[Será validado que é possível buscar todos os blogpost quando passa a busca vazia]

Se a buscar for vazia o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

  // GET /post/search?q=

  [
    {
      "id": 1,
      "title": "Post do Ano",
      "content": "Melhor post do ano",
      "userId": 1,
      "published": "2011-08-01T19:58:00.000Z",
      "updated": "2011-08-01T19:58:51.000Z",
      "user": {
        "id": 1,
        "displayName": "Lewis Hamilton",
        "email": "lewishamilton@gmail.com",
        "image": "https://upload.wikimedia.org/wikipedia/commons/1/18/Lewis_Hamilton_2016_Malaysia_2.jpg"
      },
      "categories": [
        {
          "id": 1,
          "name": "Inovação"
        }
      ]
    },
    
    /* ... */
  ]

[Será validado que é possível buscar um blogpost inexistente e retornar array vazio]
- Se a buscar um post inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:
```
  // GET /post/search?q=BATATA

  []
```

Name		Name	Last commit message	Last commit date
Latest commit History 10 Commits
.github		.github
.trybe		.trybe
.vscode		.vscode
__tests__		__tests__
public		public
src		src
.eslintignore		.eslintignore
.eslintrc.json		.eslintrc.json
.gitignore		.gitignore
.sequelizerc		.sequelizerc
Dockerfile		Dockerfile
README.md		README.md
docker-compose.yml		docker-compose.yml
jest.config.js		jest.config.js
package-lock.json		package-lock.json
package.json		package.json
trybe.yml		trybe.yml

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

Boas-vindas ao repositório do projeto API de Blogs!

Desafios

1 - Crie migrations para as tabelas `users`, `categories`, `blog_posts`, `posts_categories`

2 - Crie o modelo `User` em `src/models/User.js` com as propriedades corretas

3 - Sua aplicação deve ter o endpoint POST `/login`

4 - Sua aplicação deve ter o endpoint POST `/user`

⚠️ Validando token nas requisições

5 - Sua aplicação deve ter o endpoint GET `/user`

6 - Sua aplicação deve ter o endpoint GET `/user/:id`

7 - Crie o modelo `Category` em `src/models/Category.js` com as propriedades corretas

8 - Sua aplicação deve ter o endpoint POST `/categories`

9 - Sua aplicação deve ter o endpoint GET `/categories`

10 - Crie o modelo `BlogPost` em `src/models/BlogPost.js` com as propriedades e associações corretas

11 - Crie o modelo `PostCategory` em `src/models/PostCategory.js` com as propriedades e associações corretas

12 - Sua aplicação deve ter o endpoint POST `/post`

13 - Sua aplicação deve ter o endpoint GET `/post`

14 - Sua aplicação deve ter o endpoint GET `/post/:id`

15 - Sua aplicação deve ter o endpoint PUT `/post/:id`

Requisitos Bônus

16 - Sua aplicação deve ter o endpoint DELETE `/post/:id`

17 - Sua aplicação deve ter o endpoint DELETE `/user/me`

18 - Sua aplicação deve ter o endpoint GET `/post/search?q=:searchTerm`

About

Releases

Packages

Languages

FranciscoVieir/Project-blogs-api

Folders and files

Latest commit

History

Repository files navigation

Boas-vindas ao repositório do projeto API de Blogs!

Desafios

1 - Crie migrations para as tabelas users, categories, blog_posts, posts_categories

2 - Crie o modelo User em src/models/User.js com as propriedades corretas

3 - Sua aplicação deve ter o endpoint POST /login

4 - Sua aplicação deve ter o endpoint POST /user

⚠️ Validando token nas requisições

5 - Sua aplicação deve ter o endpoint GET /user

6 - Sua aplicação deve ter o endpoint GET /user/:id

7 - Crie o modelo Category em src/models/Category.js com as propriedades corretas

8 - Sua aplicação deve ter o endpoint POST /categories

9 - Sua aplicação deve ter o endpoint GET /categories

10 - Crie o modelo BlogPost em src/models/BlogPost.js com as propriedades e associações corretas

11 - Crie o modelo PostCategory em src/models/PostCategory.js com as propriedades e associações corretas

12 - Sua aplicação deve ter o endpoint POST /post

13 - Sua aplicação deve ter o endpoint GET /post

14 - Sua aplicação deve ter o endpoint GET /post/:id

15 - Sua aplicação deve ter o endpoint PUT /post/:id

Requisitos Bônus

16 - Sua aplicação deve ter o endpoint DELETE /post/:id

17 - Sua aplicação deve ter o endpoint DELETE /user/me

18 - Sua aplicação deve ter o endpoint GET /post/search?q=:searchTerm

About

Topics

Resources

Stars

Watchers

Forks

Releases

Packages 0

Languages

1 - Crie migrations para as tabelas `users`, `categories`, `blog_posts`, `posts_categories`

2 - Crie o modelo `User` em `src/models/User.js` com as propriedades corretas

3 - Sua aplicação deve ter o endpoint POST `/login`

4 - Sua aplicação deve ter o endpoint POST `/user`

5 - Sua aplicação deve ter o endpoint GET `/user`

6 - Sua aplicação deve ter o endpoint GET `/user/:id`

7 - Crie o modelo `Category` em `src/models/Category.js` com as propriedades corretas

8 - Sua aplicação deve ter o endpoint POST `/categories`

9 - Sua aplicação deve ter o endpoint GET `/categories`

10 - Crie o modelo `BlogPost` em `src/models/BlogPost.js` com as propriedades e associações corretas

11 - Crie o modelo `PostCategory` em `src/models/PostCategory.js` com as propriedades e associações corretas

12 - Sua aplicação deve ter o endpoint POST `/post`

13 - Sua aplicação deve ter o endpoint GET `/post`

14 - Sua aplicação deve ter o endpoint GET `/post/:id`

15 - Sua aplicação deve ter o endpoint PUT `/post/:id`

16 - Sua aplicação deve ter o endpoint DELETE `/post/:id`

17 - Sua aplicação deve ter o endpoint DELETE `/user/me`

18 - Sua aplicação deve ter o endpoint GET `/post/search?q=:searchTerm`

Packages