Telefonia API Rest com Flask

No contexto de um Agente Virtual de Telefonia, é utilizada uma base de telefones para a realização de acionamentos. Dessa forma, neste cenário, é necessário inibir alguns casos, ou seja, não discar para telefones de clientes específicos.

Esse projeto representa uma API REST para o gerenciamento do bloqueio de números em acionamentos telefônicos, utilizando Python 3.8.3 e Flask.

Fazendo funcionar

Para rodar a API em seu ambiente local, siga os tópicos abaixo.

Configurando

Após clonar este repositório e ter a versão do Python compatível instalada, é necessário ativar o venv.

Em seguida, execute o comando abaixo para instalar as bibliotecas necessárias:

pip install -r requirements.txt

O pip se encarregará de instalar as bibliotecas nas versões especificadas pelo arquivo requirements.txt.

Executando

Para rodar a API, você deverá executar o seguinte comando no seu terminal.

Lembre-se: é necessário ter o venv habilitado.

Terminal:

python app.py

Ao rodar, deve aparecer o seguinte:

Terminal:

> python app.py
 * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
 * Serving Flask app "app" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off

Para a utilização da API, você pode conferir as requisições possíveis e como utilizar cada uma delas acessando o Swagger, ferramenta visual e interativa instalada junto à API, através da URL do Swagger dessa API.

Sobre a solução

A construção da presente API se deu pelos seguintes requisitos básicos:

Consultar 1 ou n telefones para verificar se é válido para discagem.
Cadastrar 1 ou n telefones na lista de bloqueio.
Remover 1 ou n telefones na lista de bloqueio.
Consultar todos os telefones.

Com base nessas informações e nas necessidades apresentadas, foi possível pensar em uma solução que se comportasse como uma blocklist, um armazenamento de números telefônicos que deveriam ser inibidos de acionamento, ao invés de armazenar todos os números telefônicos de uma base original e no banco dessa API tivessem um status de bloqueio, definido entre estar ou não bloqueado.

Escolha do banco de dados

Por isso, uma opção que facilita o desenvolvimento e cumpre de forma mais prática esse modelo esperado foi a adoção do MongoDB, especialmente pelo MongoDB Atlas. Para saber mais sobre, veja o link para a plataforma em Mais informações.

A collection foi planejada conforme o seguinte modelo:

{
    'phone_number': '1432323232 
}

Nela, phone_number é uma string, de presença obrigatória nas requisições. O schema da collection também está documentado através do Swagger.

Cada document, elemento da collection, também possui um ObjectID, com uma chave de identificação única para cada document. Porém, na API básica, que se norteia pelas quatro necessidades básicas listadas acima, o id do document não foi levado em consideração, e o phone_number é a propriedade utilizada para as operações (consultas, leituras, inserções e deleções).

Estrutura do projeto

Para a estrutura de projeto, a solução encontrada foi a divisão do escopo em três arquivos principais:

app.py para representar o Flask
manager.py para implementação das regras de negócio
database.py para integração com o banco de dados

Para possibilitar futuros desenvolvimentos de URLs e funcionalidades novas para a API, manteve-se os errorhandler em app.py e as rotas foram separadas no arquivo routes/api_routes.py.

Todas as integrações entre as requisições HTTP e a comunicação com o banco de dados são intermediados pelo manager.py, que se ocupa com as validações e permite o acréscimo prático de novas regras que se façam necessárias, além das já implementadas, como a validação de duplicidade/existência do número de telefone no banco.

Por fim, o database.py faz efetivamente a comunicação com o banco de dados, utilizando a biblioteca pymongo. Optou-se por ela, ao invés da utilização de alguma biblioteca que atuasse como wrapper do pymongo e que eventualmente permitisse um ORM justamente pela solução mais simples da API atuando como uma blocklist, evitando o armazenamento de muitas informações.

Testes unitários

O projeto também conta com testes unitários, estruturados separadamente em três TestCases, um arquivo para cada classe. Eles podem ser executados com o seguinte comando na raiz do projeto:

python -m unittest discover -s <directory_path>/tests -t <directory_path>/tests

Substitua a tag <directory_path> pelo caminho do diretório raiz do projeto clonado e, para a execução dos testes, certifique-se de que o venv está habilitado.

Deploy

Para o deploy, foi utilizado o Heroku, ferramenta de cloud para deploy (manual e/ou automatizado), principalmente pela fácil integração e deploy automático de repositórios do GitHub.

Os arquivos Procfile e runtime.txt foram adicionados ao projeto para que o deploy pudesse ser realizado pelo Heroku, e foi adicionado o gunicorn no arquivo requirements.txt como o WSGI HTTP Server.

Para conferir o projeto, que está em produção, pode-se acessar: https://telefonia-api.herokuapp.com/. Por ele, é possível também acessar a documentação da API pelo Swagger.

Próximos passos

Pensando na escalabilidade da API, pode chegar um momento em que o retorno das requisições conterá muitos casos. Para lidar com isso da forma mais elegante e simples, é necessária a paginação desses resultados.

No arquivo api_routes.py há uma função chamada __get_paginated_list, que já implementa essa paginação de acordo com os argumentos que lhe forem passados. Para a sua implementação em todas as requisições, será necessário também atualizar os testes unitários, que hoje não esperam resultados paginados, assim como também o Swagger.

joaopedroguimaraes / telefonia_api