Boas vindas ao repositório do API de Blogs!

Termos e acordos

Ao iniciar este projeto, você concorda com as diretrizes do Código de Ética e Conduta e do Manual da Pessoa Estudante da Trybe.

Boas vindas ao repositório do API de Blogs!

Você já usa o GitHub diariamente para desenvolver os exercícios, certo? Agora, para desenvolver os projetos, você deverá seguir as instruções a seguir. Fique atento a cada passo, e se tiver qualquer dúvida, nos envie por Slack! #vqv 🚀

Aqui você vai encontrar os detalhes de como estruturar o desenvolvimento do seu projeto a partir deste repositório, utilizando uma branch específica e um Pull Request para colocar seus códigos.

Sumário

Habilidades
Entregáveis
Instruções para entregar seu projeto
Como desenvolver
- Linter
Requisitos do projeto
Avisos Finais

Habilidades

Nesse projeto, você vai construir um back-end usando ORM com o pacote sequelize do npm, e será capaz de:

Criar e associar tabelas usando models do sequelize
Construir endpoints para consumir os models que criar
Fazer um CRUD com o ORM

Entregáveis

Para entregar o seu projeto você deverá criar um Pull Request neste repositório.

Lembre-se que você pode consultar nosso conteúdo sobre Git & GitHub sempre que precisar!

O que deverá ser desenvolvido

Você vai arquiteturar, desenvolver uma API de um CRUD posts de blog (com o sequelize). Começando pela API, você vai desenvolver alguns endpoints (seguindo os princípios do REST) que estarão conectados ao seu banco de dados. Lembre-se de aplicar os princípios SOLID!

Primeiro, você irá criar uma tabela para os usuários que desejam se cadastrar na aplicação. Após isso, criará também uma tabela de Categorias para seus Posts e por fim a tabela de Posts será seu foco, guardando todas as informações dos posts realizados na plataforma. Essa é apenas uma recomendação!

Desenvolvimento

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

Para fazer um post é necessário usuário e login, portanto será trabalhada a relação entre user e post. Também será necessário a utlização de categorias para seus posts, assim trabalhando a relação de posts para categorias e de categorias para posts.

Data de Entrega

Projeto individual.
Serão 3 dias de projeto.
Data de entrega para avaliação final do projeto: 22/10/2021 - 14:00h.

Instruções para entregar seu projeto:

ANTES DE COMEÇAR A DESENVOLVER:

Clone o repositório

git clone https://github.com/tryber/sd-010-b-project-blogs-api.git.
Entre na pasta do repositório que você acabou de clonar:
- cd sd-010-b-project-blogs-api

Instale as dependências [Caso existam]

npm install

Crie uma branch a partir da branch master

Verifique que você está na branch master
- Exemplo: git branch
Se não estiver, mude para a branch master
- Exemplo: git checkout master
Agora crie uma branch à qual você vai submeter os commits do seu projeto
- Você deve criar uma branch no seguinte formato: nome-de-usuario-nome-do-projeto
- Exemplo: git checkout -b joaozinho-sd-010-b-project-blogs-api

Adicione as mudanças ao stage do Git e faça um commit

Verifique que as mudanças ainda não estão no stage
- Exemplo: git status (deve aparecer listada a pasta joaozinho em vermelho)
Adicione o novo arquivo ao stage do Git
- Exemplo:
  - git add . (adicionando todas as mudanças - que estavam em vermelho - ao stage do Git)
  - git status (deve aparecer listado o arquivo joaozinho/README.md em verde)
Faça o commit inicial
- Exemplo:
  - git commit -m 'iniciando o projeto x' (fazendo o primeiro commit)
  - git status (deve aparecer uma mensagem tipo nothing to commit )

Adicione a sua branch com o novo commit ao repositório remoto

Usando o exemplo anterior: git push -u origin joaozinho-sd-010-b-project-blogs-api

Crie um novo Pull Request (PR)

Vá até a página de Pull Requests do repositório no GitHub
Clique no botão verde "New pull request"
Clique na caixa de seleção "Compare" e escolha a sua branch com atenção
Clique no botão verde "Create pull request"
Adicione uma descrição para o Pull Request e clique no botão verde "Create pull request"
Não se preocupe em preencher mais nada por enquanto!
Volte até a página de Pull Requests do repositório e confira que o seu Pull Request está criado

DURANTE O DESENVOLVIMENTO

Faça commits das alterações que você fizer no código regularmente
Lembre-se de sempre após um (ou alguns) commits atualizar o repositório remoto
Os comandos que você utilizará com mais frequência são:
1. git status (para verificar o que está em vermelho - fora do stage - e o que está em verde - no stage)
2. git add (para adicionar arquivos ao stage do Git)
3. git commit (para criar um commit com os arquivos que estão no stage do Git)
4. git push -u nome-da-branch (para enviar o commit para o repositório remoto na primeira vez que fizer o push de uma nova branch)
5. git push (para enviar o commit para o repositório remoto após o passo anterior)

Execução de testes unitários

Vamos usar o Jest para executar os testes, use o comando a seguir para executar todos os testes:

npm test

Caso queria executar só um arquivo de test use o seguinte comando, considerado que quer testar o arquivo tests/req07-createPost.test.js:

npm test tests/req07-createPost.test.js

ou

npm test req07

Como desenvolver

Linter

Para garantir a qualidade do código, usaremos o ESLint para fazer a sua análise estática.

Este projeto já vem com as dependências relacionadas ao linter configuradas nos arquivos package.json nos seguintes caminhos:

sd-010-b-project-blogs-api/package.json

Para poder rodar os ESLint em um projeto basta executar o comando npm install dentro do projeto e depois npm run lint. Se a análise do ESLint encontrar problemas no seu código, tais problemas serão mostrados no seu terminal. Se não houver problema no seu código, nada será impresso no seu terminal.

Você também pode instalar o plugin do ESLint no VSCode, bastar ir em extensions e baixar o plugin ESLint.

⚠ PULL REQUESTS COM ISSUES DE LINTER NÃO SERÃO AVALIADAS. ATENTE-SE PARA RESOLVÊ-LAS ANTES DE FINALIZAR O DESENVOLVIMENTO! ⚠

Requisitos do projeto:

Antes de começar:

⚠️ Leia-os atentamente e siga à risca o que for pedido. ⚠️

👀 Observações importantes:

Em cada requisito você encontrará uma imagem de um protótipo de como sua aplicação deve ficar. Estilo da página não será avaliado.

O não cumprimento de um requisito, total ou parcialmente, impactará em sua avaliação.

Há um arquivo index.js no repositório. Não remova, nele, o seguinte trecho de código:

app.get('/', (request, response) => {
  response.send();
});

Você irá precisar configurar as variáveis globais do MySQL. Você pode usar esse Conteúdo de variáveis de ambiente com NodeJS como referência.

Faça essas configurações também para as variáveis de ambiente usadas nesses arquivo:

sd-010-b-project-blogs-api/config/config.js

module.exports = {
  development: {
    username: process.env.MYSQL_USER,
    password: process.env.MYSQL_PASSWORD,
    database: 'blogs_api',
    host: process.env.HOSTNAME,
    dialect: 'mysql',
  },
  test: {
    username: process.env.MYSQL_USER,
    password: process.env.MYSQL_PASSWORD,
    database: 'blogs_api',
    host: process.env.HOSTNAME,
    dialect: 'mysql',
  },
  production: {
    username: process.env.MYSQL_USER,
    password: process.env.MYSQL_PASSWORD,
    database: 'blogs_api',
    host: process.env.HOSTNAME,
    dialect: 'mysql',
  },
};

(Neste arquivo e obrigatório deixar o nome do database como "database": 'blogs_api')

É essencial usar essas 3 variávies no arquivo acima:

Variáveis:

host: process.env.HOSTNAME

user: process.env.MYSQL_USER

password: process.env.MYSQL_PASSWORD

Com elas que iremos conseguir conectar ao banco do avaliador automático

Variável JWT (opcional):

JWT_SECRET

Também poderá ser utilizada esta variável de ambiente para o SECRET do JWT

Dicas

Status HTTP

Tenha em mente que todas as "respostas" devem respeitar os status do protocolo HTTP com base no que o REST prega.

Alguns exemplos:

Requisições que precisam de token mas não o receberam devem retornar um código de status 401;
Requisições que não seguem o formato pedido pelo servidor devem retornar um código de status 400;
Um problema inesperado no servidor deve retornar um código de status 500;
Um acesso ao criar um recurso, no nosso caso usuário ou post, deve retornar um código de status 201.

Os seguintes pontos serão avaliados:

O seu projeto deverá usar um ORM para criar e atualizar o seu banco. A clonagem do projeto seguida de um comando de migrate deve deixá-lo em sua forma esperada.

Deve conter uma tabela chamada Users, contendo dados com a seguinte estrutura::

{
  "id": 1,
  "displayName": "Brett Wiltshire",
  "email": "brett@email.com", // tem quer ser único
  "password": "123456",
  "image": "http://4.bp.blogspot.com/_YA50adQ-7vQ/S1gfR_6ufpI/AAAAAAAAAAk/1ErJGgRWZDg/S45/brett.png"
}

Deve conter uma tabela chamada Categories, contendo dados com a seguinte estrutura::
```
{
  "id": 18,
  "name": "News"
}
```
Deve conter uma tabela chamada PostsCategories, contendo dados com a seguinte estrutura:
```
{
  "postId": 50,
  "categoryId": 20
}
```
Deve conter uma tabela chamada BlogPosts, contendo dados com a seguinte estrutura::
```
{
  "id": 21,
  "title": "Latest updates, August 1st",
  "content": "The whole text for the blog post goes here in this key",
  "userId": 14, // esse é o id que referência usuário que é o autor do post
  "published": "2011-08-01T19:58:00.000Z",
  "updated": "2011-08-01T19:58:51.947Z",
}
```
Os dados acima são fictícios, e estão aqui apenas como exemplo

OBS: Os testes irão rodar atráves do seu migrate usando os seguintes comandos:

"drop": "npx sequelize-cli db:drop $" -- Dropa o banco

"prestart": "npx sequelize-cli db:create && npx sequelize-cli db:migrate $" -- Cria o banco e gera as tabelas

"seed": "npx sequelize-cli db:seed:all $", -- Insere dados na tabela

Então preste bastante atenção se estiver errado o avaliador não irá funcionar

Haverá um arquivo na pasta /seeders dentro dela irá conter as querys para inserir no banco não remova ela o avaliador irá usar ela.

Lista de Requisitos:

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

Os seguintes pontos serão avaliados:

O endpoint deve ser capaz de adicionar um novo user a sua tabela no banco de dados;

O corpo da requisição deverá ter o seguinte formato:

{
  "displayName": "Brett Wiltshire",
  "email": "brett@email.com",
  "password": "123456",
  "image": "http://4.bp.blogspot.com/_YA50adQ-7vQ/S1gfR_6ufpI/AAAAAAAAAAk/1ErJGgRWZDg/S45/brett.png"
}

O campo displayName deverá ser uma string com no mínimo de 8 caracteres;
O campo email será considerado válido se tiver o formato <prefixo>@<domínio> e se for único. Ele é obrigatório.
A senha deverá conter 6 caracteres. Ela é obrigatória.
Caso exista uma pessoa com o mesmo email na base, deve-se retornar o seguinte erro:
```
{
  "message": "User already registered"
}
```

Caso contrário, retornar a mesma resposta do endpoint de /login, um token JWT:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXlsb2FkIjp7ImlkIjo1LCJkaXNwbGF5TmFtZSI6InVzdWFyaW8gZGUgdGVzdGUiLCJlbWFpbCI6InRlc3RlQGVtYWlsLmNvbSIsImltYWdlIjoibnVsbCJ9LCJpYXQiOjE2MjAyNDQxODcsImV4cCI6MTYyMDY3NjE4N30.Roc4byj6mYakYqd9LTCozU1hd9k_Vw5IWKGL4hcCVG8"
}

O token anterior é fictício

Além disso, as seguintes verificações serão feitas:

[Será validado que é possível cadastrar um usuário com sucesso]

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

[Será validado que não é possível cadastrar usuário com o campo displayName menor que 8 caracteres]

Se o usuário tiver o campo "displayName" menor que 8 caracteres o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível cadastrar usuário com o campo email com formato email: rubinho]

Se o usuário tiver o campo "email" com o formato email: rubinho o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível cadastrar usuário com o campo email com formato email: @gmail.com]

Se o usuário tiver o campo "email" com o formato email: @gmail.com o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que o campo email é obrigatório]

Se o usuário não tiver campo "email" o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível cadastrar usuário com o campo password diferente de 6 caracteres]

Se o usuário tiver o campo "password" menor ou maior que 6 caracteres o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que o campo password é obrigatório]

Se o usuário não tiver campo "password" o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Validar que não é possível cadastrar um usuário com email já existente]

Se o usuário cadastrar o campo "email" com um email que já existe, o resultado retornado deverá ser conforme exibido abaixo, com um status http 409:

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

Os seguintes pontos serão avaliados:

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

{
  "email": "email@mail.com",
  "password": "123456"
}

Caso algum desses campos seja inválido ou não exista um usuário correspondente no banco de dados, retorne um código de status 400 com o corpo { message: "Campos inválidos" }.

Caso esteja tudo certo com o login, a resposta deve ser um token JWT, no seguinte formato:

{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXlsb2FkIjp7ImlkIjo1LCJkaXNwbGF5TmFtZSI6InVzdWFyaW8gZGUgdGVzdGUiLCJlbWFpbCI6InRlc3RlQGVtYWlsLmNvbSIsImltYWdlIjoibnVsbCJ9LCJpYXQiOjE2MjAyNDQxODcsImV4cCI6MTYyMDY3NjE4N30.Roc4byj6mYakYqd9LTCozU1hd9k_Vw5IWKGL4hcCVG8"
}

O token anterior é fictício

Além disso, as seguintes verificações serão feitas:

[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:

[Será validado que não é possível fazer login sem o campo email]

Se o login não tiver o campo "email" o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível fazer login sem o campo password]

Se o login não tiver o campo "password" o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível fazer login com o campo email em branco]

Se o login tiver o campo "email" em branco o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível fazer login com o campo password em branco]

Se o login tiver o campo "password" em branco o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

(As contrabarras \ estão escapando as aspas de dentro da string)

[Será validado que não é possível fazer login com um usuário que não existe]

Se o login for com usuário inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

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

Os seguintes pontos serão avaliados:

Deve listar todos os Users e retorná-los na seguinte estrutura:

[
  {
    "id": "401465483996",
    "displayName": "Brett Wiltshire",
    "email": "brett@email.com",
    "image": "http://4.bp.blogspot.com/_YA50adQ-7vQ/S1gfR_6ufpI/AAAAAAAAAAk/1ErJGgRWZDg/S45/brett.png"
  }
]

A requisição deve ter token de autenticação nos headers e, caso contrário, retorne um código de status 401.

Além disso, as seguintes verificações serão feitas:

[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:

[Será validado que não é possível listar usuários sem o token na requisição]

Se o token for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível listar usuários com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Retorna os detalhes do usuário baseado no id da rota. Os dados devem ter o seguinte formato:

{
  "id": "401465483996",
  "displayName": "Brett Wiltshire",
  "email": "brett@email.com",
  "image": "http://4.bp.blogspot.com/_YA50adQ-7vQ/S1gfR_6ufpI/AAAAAAAAAAk/1ErJGgRWZDg/S45/brett.png"
}

A requisição deve ter token de autenticação nos headers e, caso contrário, retorne um código de status 401.

Além disso, as seguintes verificações serão feitas:

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

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

[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:

[Será validado que não é possível listar um determinado usuário sem o token na requisição]

Se o token for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível listar um determinado usuário com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Esse endpoint deve receber uma Categoria no corpo da requisição e criá-la no banco. O corpo da requisição deve ter a seguinte estrutura:

 {
   "name": "Inovação"
 }

Caso a Categoria não contenha o name a API deve retornar um erro de status 400.
A requisição deve ter o token de autenticação nos headers e, caso contrário, retorne um código de status 401.

Além disso, as seguintes verificações serão feitas:

[Será validado que é possível cadastrar uma categoria com sucesso]

Se cadastrar uma categoria com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 201:

[Será validado que não é possível cadastrar uma categoria sem o campo name]

Se ao tentar cadastrar uma categoria sem o campo name o resultado retornado deverá ser conformo exibido abaixo, com um status http 400:

[Será validado que não é possível cadastrar uma determinada categoria com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível cadastrar uma determinada categoria sem o token na requisição]

Se o token for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Esse endpoint deve listar todas as Categorias e retorná-las na seguinte estrutura:

[
  {
    "id": 1,
    "name": "Escola"
  },
  {
    "id": 2,
    "name": "Inovação"
  }
]

Além disso, as seguintes verificações serão feitas: [Será validado que é possível listar todas as categoria com sucesso]

Se buscar todas as categorias com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

[Será validado que não é possível listar as categorias com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível cadastrar uma determinada categoria sem o token na requisição]

Se o token for inexistente o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Esse endpoint deve receber um BlogPost no corpo da requisição e criá-lo no banco. O corpo da requisição deve ter a seguinte estrutura:

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

Caso o post não contenha o title, content ou categoryIds a API deve retornar um erro de status 400.
A requisição deve ter o token de autenticação nos headers e, caso contrário, retorne um código de status 401.

Além disso, as seguintes verificações serão feitas:

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

Se cadastrar um blogpost com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 201:

[Será validado que não é possível cadastrar um blogpost sem o campo title]

Se não conter o campo title o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

[Será validado que não é possível cadastrar um blogpost sem o campo content]

Se não conter o campo content o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

[Será validado que não é possível cadastrar um blogpost sem o campo categoryIds]

Se não conter o campo categoryIds o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

[Será validado que não é possível cadastrar um blogpost com uma categoryIds inexistente]

Se o campo categoryIds tiver uma categoria inexistente, o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

[Será validado que não é possível cadastrar um blogpost sem o token]

Se não conter o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível cadastrar um blogpost com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Esse endpoint deve listar todos os BlogPosts e retorná-los na seguinte estrutura:

[
  {
    "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_2017_Malaysia.jpg"
    },
    "categories": [
      {
        "id": 1,
        "name": "Inovação"
      }
    ]
  }
]

Além disso, as seguintes verificações serão feitas:

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

Se listar os blogpost com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

[Será validado que não é possível listar blogpost sem token]

Se não conter o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível listar blogpost com token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Retorna um BlogPost com o id especificado. O retorno deve ter os seguinte formato:

  {
  "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"
    }
  ]
}

Além disso, as seguintes verificações serão feitas:

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

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

[Será validado que não é possível listar um blogpost sem token]

Se não conter o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível listar um blogpost com token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível listar um blogpost inexistente]

Se o id do post for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 404:

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

Os seguintes pontos serão avaliados:

O endpoint deve receber um BlogPost que irá sobrescrever o original com o id especificado na URL. Só deve ser permitido para o usuário que criou o BlogPost.
A(s) categoria(s) do post não podem ser editadas, somente o title e content.

O corpo da requisição deve ter a seguinte estrutura:

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

Caso uma pessoa diferente de quem criou faça a requisição, deve retornar um código status 401.
Caso uma requisição sem token seja recebida, deve-se retornar um código de status 401.
Caso o post não contenha o title e/ou o content a API deve retornar um erro de status 400.

Além disso, as seguintes verificações serão feitas:

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

Se editar um blogpost com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 200:

[Será validado que não é possível editar as categorias de um blogpost]

Só será possível editar o título ou o conteúdo de um post.

[Será validado que não é possível editar um blogpost com outro usuário]

Somente o usuário que criou o post poderá edita-lo.

[Será validado que não possível editar um blogpost sem token]

Se não conter o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não possível editar um blogpost com token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não possível editar um blogpost sem o campo title]

Se não conter o campo title o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

[Será validado que não possível editar um blogpost sem o campo content]

Se não conter o campo content o resultado retornado deverá ser conforme exibido abaixo, com um status http 400:

Requisitos Bônus

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

Os seguintes pontos serão avaliados:

Deleta o post com o id especificado. Só deve ser permitido para o usuário que criou o BlogPost.
Caso uma pessoa diferente de quem criou faça a requisição, deve retornar um código status 401.
Caso uma requisição sem token seja recebida, deve-se retornar um código de status 401.
Caso o post referido não exista, deve-se retornar um código de status 404.

Além disso, as seguintes verificações serão feitas:

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

Se deletar blogpost com sucesso o resultado retornado deverá ser conforme exibido abaixo, com um status http 204:

[Será validado que não é possível deletar um blogpost com outro usuário]

Se não for o dono do blogpost o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível deletar um blogpost inexistente]

Se o blogpost nao existir o resultado retornado deverá ser conforme exibido abaixo, com um status http 404:

[Será validado que não é possível deletar um blogpost sem o token]

Se não contém o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível deletar um blogpost com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Utilizando o token de autenticação nos headers, o usuário correspondente deve ser apagado.

Além disso, as seguintes verificações serão feitas:

[Será validado que é possível excluir meu usuário com sucesso]

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

[Será validado que não é possivel excluir meu usuário com token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possivel excluir meu usuário sem o token]

Se não conter o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

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

Os seguintes pontos serão avaliados:

Retorna uma array de BlogPosts que contenham em seu título, ou conteúdo, o termo pesquisado no queryParam da URL. O retorno deve ter o seguinte formato:

[
  {
    "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"
      }
    ]
  }
]

Caso nenhum BlogPost satisfaça a busca, retorne um array vazio.

Além disso, as seguintes verificações serão feitas:

[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:

[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:

[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:

[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:

[Será validado que não é possível buscar um blogpost sem o token]

Se não contém o token o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

[Será validado que não é possível buscar um blogpost com o token inválido]

Se o token for inválido o resultado retornado deverá ser conforme exibido abaixo, com um status http 401:

Depois de terminar o desenvolvimento

Para "entregar" seu projeto, siga os passos a seguir:

Vá até a página DO SEU Pull Request, adicione a label de "code-review" e marque seus colegas
- No menu à direita, clique no link "Labels" e escolha a label code-review
- No menu à direita, clique no link "Assignees" e escolha o seu usuário
- No menu à direita, clique no link "Reviewers" e digite students, selecione o time tryber/students-sd-010-b

Se ainda houver alguma dúvida sobre como entregar seu projeto, aqui tem um video explicativo.

⚠ Lembre-se que garantir que todas as issues comentadas pelo Lint estão resolvidas! ⚠

Revisando um pull request

À medida que você e as outras pessoas que estudam na Trybe forem entregando os projetos, vocês receberão um alerta via Slack para também fazer a revisão dos Pull Requests dos seus colegas. Fiquem atentos às mensagens do "Pull Reminders" no Slack!

Use o material que você já viu sobre Code Review para te ajudar a revisar os projetos que chegaram para você.

Avisos Finais

Ao finalizar e submeter o projeto, não se esqueça de avaliar sua experiência preenchendo o formulário. Leva menos de 3 minutos!

Link: FORMULÁRIO DE AVALIAÇÃO DE PROJETO

O avaliador automático não necessariamente avalia seu projeto na ordem em que os requisitos aparecem no readme. Isso acontece para deixar o processo de avaliação mais rápido. Então, não se assuste se isso acontecer, ok?

Name		Name	Last commit message	Last commit date
Latest commit History 32 Commits
.github		.github
.idea		.idea
.trybe		.trybe
api/auth		api/auth
config		config
controllers		controllers
middlewares		middlewares
migrations		migrations
models		models
public		public
routes		routes
seeders		seeders
tests		tests
.eslintignore		.eslintignore
.eslintrc.json		.eslintrc.json
.gitignore		.gitignore
README.md		README.md
index.js		index.js
package-lock.json		package-lock.json
package.json		package.json
yarn.lock		yarn.lock

PedroSincero/Blogs-API

Folders and files

Latest commit

History

Repository files navigation

Termos e acordos

Boas vindas ao repositório do API de Blogs!

Sumário

Habilidades

Entregáveis

O que deverá ser desenvolvido

Desenvolvimento

Data de Entrega

Instruções para entregar seu projeto:

ANTES DE COMEÇAR A DESENVOLVER:

DURANTE O DESENVOLVIMENTO

Execução de testes unitários

Como desenvolver

Linter

Requisitos do projeto:

Antes de começar:

⚠️ Leia-os atentamente e siga à risca o que for pedido. ⚠️

👀 Observações importantes:

Variáveis:

Variável JWT (opcional):

Dicas

Status HTTP

Os seguintes pontos serão avaliados:

Lista de Requisitos:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

Requisitos Bônus

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

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

Os seguintes pontos serão avaliados:

Além disso, as seguintes verificações serão feitas:

Depois de terminar o desenvolvimento

Revisando um pull request

Avisos Finais

About

Topics

Resources

Stars

Watchers

Forks

Releases

Packages 0

Contributors 3

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

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

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

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

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

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

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

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

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

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

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

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

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

Packages