-
- 1 - Minha aplicação tem o endpoint POST
/user - 2 - Minha aplicação tem o endpoint POST
/login - 3 - Minha aplicação tem o endpoint GET
/user - 4 - Minha aplicação tem o endpoint GET
/user/:id - 5 - Minha aplicação tem o endpoint POST
/categories - 6 - Minha aplicação tem o endpoint GET
/categories - 7 - Minha aplicação tem o endpoint POST
/post - 8 - Minha aplicação tem o endpoint GET
/post - 9 - Minha aplicação tem o endpoint GET
post/:id - 10 - Minha aplicação tem o endpoint PUT
/post/:id - Requisitos Bônus
- 11 - Minha aplicação tem o endpoint DELETE
post/:id
- 1 - Minha aplicação tem o endpoint POST
Nesse projeto consegui construír um back-end usando ORM com o pacote sequelize do npm e fui capaz de:
- Criar e associar tabelas usando
modelsdosequelize - Construir endpoints para consumir os models que criar
- Fazer um
CRUDcom oORM
Eu construí e desenvolvi uma API de um CRUD posts de um blog (com o Sequelize). Começando pela API, eu desenvolvi alguns endpoints (seguindo os princípios do REST & S.O.L.I.D.) que estarão conectados ao seu banco de dados.
Primeiro, eu criei uma tabela para os usuários que desejam se cadastrar na aplicação. Após isso, também uma tabela de Categorias para seus Posts e por fim a tabela de Posts foi meu foco, guardando todas as informações dos posts realizados na plataforma, além de criar uma tabela relacionando Posts e Categorias associadas por Foreign Key. Essa sequência é apenas uma recomendação!
Foi desenvolvido 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.
- Clone o repositório
git clone git@github.com:flavioCoder1/Blogs-API-GIT.git.- Entre na pasta do repositório que você acabou de clonar:
cd Blogs-API-GIT
- Instale as dependências [Caso existam]
npm install
- Inicie o ORM e rode o CLI no terminal:
https://www.npmjs.com/package/sequelize
https://www.npmjs.com/package/sequelize-cli
ALIAS:
"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
npm i sequelize E npm i sequelize-cli
-
Para dropar: "npx sequelize-cli db:drop "
-
Cria o banco e gera as tabelas: "npx sequelize-cli db:create && npx sequelize-cli db:migrate "
-
Insere os dados nas tabelas: "npx sequelize-cli db:seed:all "
- Rode o ORM (Sequelize-CLI) e o Node (npm start) e execute as requisições onde preferir (Utilizei o Insomnia (https://insomnia.rest/))
Vamos usar o Jest para executar os testes, use o comando a seguir para executar todos os testes:
npm testCaso 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.jsou
npm test req07
-
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
displayNamedeverá ser uma string com no mínimo de 8 caracteres; -
O campo
emailserá 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 tokenJWT:{ "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXlsb2FkIjp7ImlkIjo1LCJkaXNwbGF5TmFtZSI6InVzdWFyaW8gZGUgdGVzdGUiLCJlbWFpbCI6InRlc3RlQGVtYWlsLmNvbSIsImltYWdlIjoibnVsbCJ9LCJpYXQiOjE2MjAyNDQxODcsImV4cCI6MTYyMDY3NjE4N30.Roc4byj6mYakYqd9LTCozU1hd9k_Vw5IWKGL4hcCVG8" }O token anterior é fictício
[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:
-
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
[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:
-
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.
[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:
-
Retorna os detalhes do usuário baseado no
idda 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.
[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:
- 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
namea API deve retornar um erro destatus 400. -
A requisição deve ter o token de autenticação nos headers e, caso contrário, retorne um código de
status 401.
[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:
- 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:
-
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,contentoucategoryIdsa API deve retornar um erro destatus 400. -
A requisição deve ter o token de autenticação nos headers e, caso contrário, retorne um código de
status 401.
[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:
- 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"
}
]
}
][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:
- Retorna um BlogPost com o
idespecificado. 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"
}
]
}[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:
-
O endpoint deve receber um BlogPost que irá sobrescrever o original com o
idespecificado 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
titleecontent. -
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
titlee/ou ocontenta API deve retornar um erro destatus 400.
[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:
-
Deleta o post com o
idespecificado. 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.
[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:
- Projeto proposto pela Trybe e requisitos desenvolvidos por Flavio Cordeiro