API com Django 3: Validações, buscas, filtros e deploy

Iniciando o projeto - Introdução

Olá, meu nome é Guilherme Lima e eu serei o seu instrutor nesse treinamento de API com Django 3, validações, buscas, filtros e deploy.

Nesse treinamento, o que vamos aprender? Vamos aprender a incluir validações nos nossos modelos, nos nossos serializers, como trabalhar com mensagens de erro, vamos incluir nos nossos endpoints, paginação, ordenação, buscas, filtros e o mais legal de tudo, vamos colocar a nossa API no ar, vamos realizar o deploy da nossa API.

Fazendo esse curso, vamos desenvolver o seguinte projeto. Observe que estou rodando esse projeto no meu escopo local. Então, eu tenho aqui a minha lista de clientes e os meus campos com as devidas validações, nome, email, CPF, RG, celular e uma flag para indicar se esse cliente é ativo ou não na minha API.

Quando eu colocar minha API no ar e ligar e clicar para listar esses e- mails é necessário que eu faça uma autenticação. Então vou colocar meu nome, minha senha e quando dou um “enter”, observem que vamos disponibilizar os dados da nossa API com todos os filtros que citei.

Então vamos conseguir filtrar só os clientes que estão ativos, só os clientes que não estão ativos, vai conseguir ordenar através do nome de forma ascendente ou descendente e pesquisar os clientes através do campo nome ou do campo CPF.

Quais são os pré-requisitos para realizar esse treinamento? É importante que você tenha familiaridade com a linguagem de programação “Python” e já tenha trabalhado com projeto de Django Rest Framework, que você saiba os fundamentos de uma aplicação criada com esse framework, saiba o que é um “Serializer”, o que é um “Modelo”, o que é um “View”, o que é um “View7”, o que é um “Default Router”. Isso são requisitos importantes para realizarmos esse treinamAento.

E para quem é esse curso? Esse curso é recomendado para todas as pessoas que querem aperfeiçoar os seus conhecimentos nesse framework, incluindo validações, trabalhando com mensagens de erro, ou seja, aprendendo bastante coisa legal. Porém, se você já é um profissional que trabalha nessa área e já trabalhando com Django Rest Frame e há muitos anos já está inserido no mercado, talvez esse curso não seja recomendado para você.

Bom, sabendo de tudo isso, vamos começar?!

Iniciando o projeto - Conhecendo o projeto

Vamos iniciar então o desenvolvimento da nossa API e aprofundar o nosso conhecimento com o Django Rest?

Para começar, já temos um projeto que vamos utilizar como base e você pode fazer download deste projeto na atividade anterior a esse vídeo, no “Preparando Ambiente”.

Eu fiz o download do projeto aqui, e a primeira coisa que vou fazer é mudar esse nome “drf_projeto_inicial_master”. Vou chamar de “Projeto_clientes”.

Vou utilizar o “VScode” como editor de código, vou abrir ele aqui dentro, então vou arrastar ele para dentro do nosso projeto. Temos então o nosso projeto que vamos utilizar nesse curso para aprender vários outros fundamentos e aprofundar nossos conhecimentos.

Para começar, temos “clientes” que é um app e temos setup, onde vamos manter toda a configuração desse projeto.

Para começar, vou clicar em “settings” “PROJETO_CLIENTES > setup > settings.py” para entendermos como que está e o que tem nesse “settings.py”. Assim que eu abro o ´settings.py´, abre uma mensagem de erro que fala “ Aqui é um arquivo Python e você não selecionou nenhum interpretador “Python” para esse ambiente”. Vou fechar e já vamos resolver esse problema logo mais.

Então vamos ver, descendo um pouco a página, as informações importantes são Apps Instalados “INSTALLED_APPS” e temos rest_framework e tem o app de “clientes”. Já vamos descobrir.

O nosso banco de dados para esse curso vai ser o “SQLite3” mesmo e poderíamos utilizar o Postgres ou uma SQL, assim como conteúdos que já vimos em outros cursos também. Mas, para esse curso o “SQLite3” é suficiente para nós.

A língua nativa LANGUAGE_CODE = pt=br vai ser o português do Brasil e o time zone TIME_ZONE vai ser o horário de São Paulo, então America/Sao Paulo .

Indo em “urls.py” “PROJETO_CLIENTES > setup > urls.py” vamos ver que já existe uma rota criada, um registro criado para o nosso cliente, e já temos o ´ClientesViewSet´ preparado para funcionar.

Vamos conhecer então o app de clientes. Em “PROJETO_CLIENTES>clientes” temos a parte de migrações, temos o ´admin.py´ cadastrado e preparado para o nosso app de clientes, temos um modelo com nome, e-mail, CPF, RG, celular e um campo “Boolean” indicando se ele é ativo ou não.

Temos já o “serializer” , o cliente “serializer” criado através do modo ´serializer´ e para finalizar, em “view.py”, temos o ´ClientesViewSet´ . Todo o conteúdo que está descrito nesta aplicação são conteúdos que já vimos no curso anterior.

Como eu faço para essa aplicação funcionar aqui na minha máquina? Observe que estamos falando de uma aplicação “Django“ que tem o “Django Rest Framework” instalado, que tem vários outros módulos e pacotes instalados. Quais são os pacotes que eu preciso instalar e aonde eu vou instalar esses pacotes?

Bom, para começar vamos criar um ambiente virtual para essa aplicação e vai instalar todos os módulos necessários para esse projeto funcionar descritos no arquivo txt. “requeriments.txt” .

Tudo que esse projeto precisa para ele funcionar está em “PROJETO_CLIENTES > requeriments.txt” . Ele vai precisar do “Django”, do “djangorestframework”, vai precisar do ´lazy-object-proxy´ e todos os outros módulos descritos, os 14 módulos descritos.

Como vamos fazer isso? Vou abrir meu terminal com "Cmd + J” e fechar essa linha do lado com “Cmd + B” e vou começar a criar um ambiente virtual para essa aplicação.

Então primeiro ´python -m venv ./venv´ e quando dou um “enter”, ele criou a minha ´venv´ e ele já percebeu que criamos um ambiente virtual. Vou fechar essa mensagem do VScode pra fazermos mais manual.

Então criei a minha “venv”, vou ativá-la colocando ´source venv/bin/activate´. Ativei minha “venv”. Quais são os módulos que já tenho instalado nesse “venv”? Vamos descobrir?

Se eu digito ´pip freeze´ e dou um “enter”, observe que não acontece nada. Ele vem para baixo, não temos nenhum módulo instalado e vamos precisar de todos esses módulos que temos em ´requirements.txt´.

Será que vou ter que instalar um a um na mão? Não. Tem uma forma que podemos pedir para o “pip” instalar todos esses módulos para nós. Vamos colocar ´pip install - r requirements.txt´ .

Quando der um “enter” o que vai acontecer? Ele vai começar a pegar um a um e vai instalar todas as dependências desses módulos e todas as dependências que estão descritas no nosso “arquivo txt”.

Assim que terminamos ele pergunta se não queremos atualizar nosso “pip”. Vamos fazer isso também, então ´pip install --upgrade pip´ e eu vou instalar o “pip” e para finalizar. Observe que temos aqui na barra inferior do programa, em amarelo, “Selected python interpreter”. O VScode está quase gritando “Por favor, seleciona para nós o interpretador python”.

Quando clicamos na mensagem e scrollamos para baixo vamos ter o Python da ´venv´, que é o que queremos. Então vou selecionar essa opção ´Python 3.7.4 64-bit (venv: venv) ´.

Então já temos o interpretador, já tem o ambiente virtual, já tem todos os módulos instalados para essa “venv” aqui. O que eu vou fazer? Vou rodar minha aplicação ´pyhton manage. py runserver´.

Assim que eu rodo, observe. Ele dá uma mensagem assim: “Você tem 17 migrações pendentes, talvez seu projeto não funcione como você espera porque ele vai precisar da estrutura no banco de dados do “admin”, “auth”, “contenttypes” e “sessie” “. Ele falou “Considere rodar o arquivo, executar no nosso terminal, o ´python manage.py migrate´” .

O que eu vou fazer? Vou parar meu servidor, vou nem abrir meu projeto e vou rodar dois códigos. O primeiro é para ele verificar se tem alguma migração para ele gerar essas migrações para mim.

Então vou utilizar o comando ´python manage.py makemigrations´ e vou dar um “enter”. O que ele percebeu? Que existe uma migração de clientes.

O que vou fazer agora? Vou criar toda a estrutura que o Django precisa, mais essa estrutura de clientes. Então vou utilizar o comando ´python manage.py migrate´ e quando eu der um “enter” ele vai gerar no banco de dados toda a estrutura para mim.

Para finalizar eu vou rodar de novo o ´python manage.py runserver ´e não temos mais aquela mensagem. Subiu a minha aplicação e se eu for numa aba e digitar “localhost: 8000” eu vou conseguir ver que minha aplicação está sendo executada corretamente..

Se eu clico no app de “clientes” eu consigo criar os meus clientes com todos os campos já descritos. então vou criar o primeiro cliente, vai ser eu mesmo. então Guilherme, email vai ser gui@alura.com, e o cpf sabemos que o cpf tem 11 dígitos então vou deixar 11 dígitos mas tudo com numero 1. O RG tem 9 dígitos então tudo com 1 também. Vou colocar um número de celular 11990909090 e vou dizer que esse cliente Guilherme é ativo.

Quando eu dou um post temos lá o cliente Guilherme registrado. Só que se pararmos para pensar, vamos supor que todas essas informações de RG, CPF, celular, são válidas, um usuário super bonzinho que estava mexendo na nossa API.

Mas e se eu quiser registrar um usuário com nome de : 1234, e-mail: 1234, CPF: 1234, RG: 1234, e celular: 1234. O que vai acontecer com a nossa aplicação? O que vai acontecer com o nosso código? Quando eu dou um post observe que vamos ter uma mensagem de erro. De todos os campos ele só conseguiu identificar uma mensagem, que foi o campo e-mail que ele fala “Insira um endereço de e-mail válido”.

Por que isso está acontecendo? Isso acontece porque lá no nosso modelo, se eu abro “PROJETO_CLIENTES > clientes > models.py” temos uma descrição do campo e-mail com o ´models.EmailField´. Por causa desse campo conseguimos entender que o nosso e-mail precisa ter o arroba, precisa ter o “ponto com” alguma coisa.

Então se eu vier no campo do e-mail e colocar “1234@” e der um post, ele ainda está inválido. Se eu colocar “1234@alura.com” e der um post conseguimos registar. E a única verificação, validação de campo que tivemos, foi no campo e-mail, só que o nome 1234, RG, CPF, celular tudo 1234, não está muito legal.

Então o que vamos aprender nas aulas seguintes? A validar esses campos. Como que garantimos ou fazemos o máximo possível para garantir que não entre dados incorretos na nossa base da nossa API?

Iniciando o projeto - Valor único

Agora que já entendemos melhor como funciona a nossa API e clientes e como estão esses campos, parece que de todos esses campos que temos, o único campo que exige uma verificação um pouco melhor é o e-mail por conta do nosso modelo ´models.EmailField´. Ele espera que tenhamos o nome do e-mail, o “arroba” e o “ponto com” alguma coisa.

O que eu quero fazer agora é aos poucos colocar validação, e tentar garantir que os dados que a nossa API vai receber são dados corretos. Podemos começar com o CPF. Não vamos validar o número do CPF exato, existe um algoritmo que faz essa validação, não vamos fazer isso agora, vamos fazer mais para frente no curso.

O que eu quero fazer é garantir que nenhum CPF vai ser igual ao outro, quero garantir a exclusividade do CPF. Mas isso eu faço onde? Faço no meu modelo ou faço no serializer? Bom, podemos fazer no modelo e verificar se o nosso serializer puxa essa validação que vem do nosso modelo ´models.py´. Vamos fazer isso?

O que eu vou fazer é o seguinte, no nosso campo CPF dentro do nosso ´models.py´ eu vou colocar uma tag indicando que ele deve ser único, então vou colocar a propriedade ´unique=True´ . Vou falar que o CPF precisa ser único.

Vou “salvar” e abrir meu terminal, deixa eu parar esse servidor com “Crtl + C” e vou rodar o ´python manage.py makemigrations´ que alteramos nossa base de dados. Ele percebeu. Opa, apareceu que existe um campo alterado, uma alteração no campo CPF de clientes, é isso que queremos, e eu quero migrar isso para o nosso banco de dados agora.

Vou colocar então ´python manage.py migrate´, apliquei essa migração. O que vou fazer agora? Vamos subir nosso servidor com ´python manage.py runserver´. E o que eu quero fazer é tentar criar mais uma pessoa com esse RG que colocamos de 111111111.

Então vou até copiar esse RG para garantirmos esses 11 dígitos apenas com 1 e vamos ver que isso não vai ser possível. então vou usar o mesmo nome e e-mail, o CPF vou usar 11111111111 o RG vou colocar 1234, celular vou colocar qualquer celular e vou falar que ele é ativo

Quando eu der um post ele vai falar “cliente com CPF já existe”. Era o que queríamos. Mas essa validação está acontecendo no momento da instância do modelo ou no nosso serializer? Vamos verificar isso?

Para isso vou abrir um outro terminal, observe que já estou com minha ´venv´, vou fazer o seguinte, vou acessar o “Shell” do Python para importarmos essa classe de clientes “serializer´ e vamos verificar que é o CPF. Existe uma propriedade das validações, o “serializer” puxa a validações que estão nos nossos modelos.

Então para eu acessar o meu shell, vou colocar ´python manage.py shell´, com dois L’s . Acessei o “Shell”, o que vou fazer agora é importar para meu módulo interativo essa minha classe de clientes ´serializer´.

Então vou fazer da seguinte forma, vou dizer que do meu ´clientes.serializers´ eu quero importar o meu ClienteSerializer, ficando >>> from clientes.serializers import ClienteSerializer´. E dou um enter.

Eu importei o cliente e o que eu vou fazer? Agora que eu trouxe esse meu cliente ´serializer´, eu vou dizer que o meu serializer é igual a ClienteSerializer e vou dizer que ele é uma instância desse meu cliente ´serializer´, então >>> s = ClienteSerializer(). Então meu “s” é uma instância de clientes ´serializer´.

O que eu quero fazer agora é visualizar, então vou colocar um “print”, a forma como esse meu cliente está sendo representado. Então vou colocar repr para representar esse meu cliente serializer, fechando a função do s e o segundo parênteses do “print” ficando >>>print (repr(s)).

Quando dou um “enter” observe que ele vai mostrar para nós os detalhes desse meu cliente serializer, então o id é um IntegerField com label ID, disponível apenas para o modo de leitura, o nome é um ´CharField´ de no máximo 100 caracteres, o e-mail com no máximo 30, o CPF é um CharField com no máximo 11 caracteres e dentro do CPF temos o ´validators´.

Observe que interessante, ele trouxe e incluiu esse validators e indicando que temos um valor único mostrado em ´UniqueValidator´. Ou seja, dessa forma te garantimos que todas as validações que incluirmos no nosso modelo serão puxadas pelo nosso serializer também.

Então, por exemplo, podemos testar também. Vou criar um RG com mais números. Então no nosso RG vou colocar “1234123412341234”, eu ultrapassei os números do meu RG. Observe que depois que damos o post, aparece uma mensagem em vermelho dizendo “certifique-se que esse campo não tenha mais do que 9 caracteres”.

Não escrevemos essas mensagens de erro, mas só de inserirmos esses detalhes nos nossos modelos, já conseguimos puxar essas validações para o nosso serializer também

O que vamos ver na sequência? Vamos aprender a incluir as validações direto no serializer e ver quais são as vantagens dessa atitude.

Sobre o curso API com Django 3: Validações, buscas, filtros e deploy

O curso API com Django 3: Validações, buscas, filtros e deploy possui 147 minutos de vídeos, em um total de 44 atividades. Gostou? Conheça nossos outros cursos de Python em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Iniciando o projeto
• Validações no Serializer
• Importando validações e gerando clientes
• Paginação, ordenação, buscas e filtro
• Deploy