-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature de novo Endpoint para verificação de área de risco dos Correios por CEP #557
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Muito obrigado pela contribuição! Deixei alguns pedidos de melhoras
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
É uma prática deste repositório deixar as versões pinadas
"dayjs": "1.11.7", | ||
"dom-parser": "^1.1.5", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pelo que vi essa dependência não é utilizada. Se for o caso, poderia remover?
// Padrões de alertas dos Correios definidos por expressões regulares. | ||
const padroesAlertasCorreios = [ | ||
{ | ||
regex: /alert\(\'CEP de origem n.*o encontrado na base de dados dos Correios \(-1\).\'\)/, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Se com a expressão regular de baixo der certo, acho interessante adotar a estratégia não gulosa
regex: /alert\(\'CEP de origem n.*o encontrado na base de dados dos Correios \(-1\).\'\)/, | |
regex: /alert\(\'CEP de origem n.*?o encontrado na base de dados dos Correios \(-1\).\'\)/, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Por qual motivo estamos lidando com matchers na acentuação? A ideia é garantir que mesmo sem saber o encoding a gnt lidar corretamente?
regex: /alert\(\'CEP de destino n.*o encontrado na base de dados dos Correios \(-2\).\'\)/, | ||
mensagem: ERROR_MESSAGES['CEP_DESTINO_NOT_FOUND'] | ||
}, | ||
{ | ||
regex: /alert\(\'CEP de destino inv.*lido.\'\)/, | ||
mensagem: ERROR_MESSAGES['CEP_DESTINO_INVALIDO'] | ||
}, | ||
{ | ||
regex: /alert\(\'CEP inv.*lido.\'\)/, | ||
mensagem: ERROR_MESSAGES['CEP_ORIGEM_INVALIDO'] | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
regex: /alert\(\'CEP de destino n.*o encontrado na base de dados dos Correios \(-2\).\'\)/, | |
mensagem: ERROR_MESSAGES['CEP_DESTINO_NOT_FOUND'] | |
}, | |
{ | |
regex: /alert\(\'CEP de destino inv.*lido.\'\)/, | |
mensagem: ERROR_MESSAGES['CEP_DESTINO_INVALIDO'] | |
}, | |
{ | |
regex: /alert\(\'CEP inv.*lido.\'\)/, | |
mensagem: ERROR_MESSAGES['CEP_ORIGEM_INVALIDO'] | |
} | |
regex: /alert\(\'CEP de destino n.*?o encontrado na base de dados dos Correios \(-2\).\'\)/, | |
mensagem: ERROR_MESSAGES['CEP_DESTINO_NOT_FOUND'] | |
}, | |
{ | |
regex: /alert\(\'CEP de destino inv.*?lido.\'\)/, | |
mensagem: ERROR_MESSAGES['CEP_DESTINO_INVALIDO'] | |
}, | |
{ | |
regex: /alert\(\'CEP inv.*?lido.\'\)/, | |
mensagem: ERROR_MESSAGES['CEP_ORIGEM_INVALIDO'] | |
} |
// Função para validar a presença dos CEPs de origem e destino. | ||
function validarCEP(cepOrigem, cepDestino) { | ||
if (!cepOrigem || !cepDestino) { | ||
throw new NotFoundError({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creio que aqui faça mais sentido um bad request
throw new NotFoundError({ | |
throw new BadRequestError({ |
}, | ||
"example": { | ||
"response": "CEP em zona restrita", | ||
"isDeliverable": false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"isDeliverable": false | |
"is_deliverable": false |
"schemas": { | ||
"cepInfo": { | ||
"title": "Informação do CEP", | ||
"required": ["response", "isDeliverable"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"required": ["response", "isDeliverable"], | |
"required": ["response", "is_deliverable"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sugeriria de deixar aqui o mais simples possível e deixar a maioria das funções e constantes dentro do service
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Será que vale criar uma rota mãe chamada /correios
e colocar dentro dela /correios/cep
e /correios/restricao
?
Obviamente ainda mantendo um symlink do cep atual pra não deixar de funionar 🤔
// Função principal que verifica restrições de entrega para um CEP. | ||
const verifyRestriction = async (request, response) => { | ||
try { | ||
const {cepOrigem, cepDestino, servico} = request.query; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acho interessante adotar o padrão snake_case para as variáveis que vêm do cliente e vão para o cliente
const {cepOrigem, cepDestino, servico} = request.query; | |
const {cep_origem: cepOrigem, cep_destino: cepDestino, servico} = request.query; |
response.status(200).json('{"response": "CEP em zona restrita", "isDeliverable": false}'); | ||
return; | ||
} | ||
|
||
if (positiveDiv) { | ||
response.status(200).json('{"response": "CEP sem restricao de entrega", "isDeliverable": true}'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
response.status(200).json('{"response": "CEP em zona restrita", "isDeliverable": false}'); | |
return; | |
} | |
if (positiveDiv) { | |
response.status(200).json('{"response": "CEP sem restricao de entrega", "isDeliverable": true}'); | |
response.status(200).json({message: "CEP em zona restrita", is_deliverable: false}); | |
return; | |
} | |
if (positiveDiv) { | |
response.status(200).json({message:"CEP sem restricao de entrega", is_deliverable": true}); |
function verificarAlertasCorreios(correiosData) { | ||
const padrao = padroesAlertasCorreios.find(p => p.regex.test(correiosData)); | ||
return padrao ? { alerta: true, mensagem: padrao.mensagem } : { alerta: false, mensagem: '' }; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dado que o esperado é que na maioria das vezes não hajam alertas será que não é melhor primeiro validar se existe um alerta e caso exista a gnt iterar sobre os possíveis alertas pra mapear corretamente o erro? (pensando especialmente que fazer validações com Regex pode ser bem exaustivo)
} | ||
|
||
// Função para validar a presença dos CEPs de origem e destino. | ||
function validarCEP(cepOrigem, cepDestino) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seria interessante manter o nome das funções em inglês como o restante da codebase 🙏
const {cepOrigem, cepDestino, servico} = request.query; | ||
|
||
// Verifica se o serviço solicitado é válido. | ||
if (!(servico in SERVICOS)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pq fazer dessa forma e não da seguinte forma?
if (!(servico in SERVICOS)) { | |
if (!SERVICOS[servico]) { |
} | ||
|
||
// Valida os CEPs fornecidos na requisição. | ||
validarCEP(cepOrigem, cepDestino); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Será que aqui um nome melhor pra função não seria validateParams
e nessa função validar os 3 parametros? 👀
]; | ||
|
||
// Função para verificar se existe algum alerta na resposta dos Correios. | ||
function verificarAlertasCorreios(correiosData) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Será que não seria mais interessante essa função se chamar getAlerts
e caso não hajam alertas o retorno é null?
const verificarAlerta = verificarAlertasCorreios(correiosData); | ||
|
||
// Se um alerta for encontrado, lança um erro. | ||
if (verificarAlerta['alerta']) { | ||
throw new NotFoundError({ | ||
message: verificarAlerta['mensagem'], | ||
type: 'cep_error', | ||
name: 'CEP_NOT_FOUND', | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partindo do comentário https://github.com/BrasilAPI/BrasilAPI/pull/557/files#r1412902104
A gnt poderia reescrever esse trecho pra algo tipo
const verificarAlerta = verificarAlertasCorreios(correiosData); | |
// Se um alerta for encontrado, lança um erro. | |
if (verificarAlerta['alerta']) { | |
throw new NotFoundError({ | |
message: verificarAlerta['mensagem'], | |
type: 'cep_error', | |
name: 'CEP_NOT_FOUND', | |
}); | |
} | |
const foundAlert = getAlert(correiosData); | |
if (foundAlert) { | |
throw new NotFoundError({ | |
message: foundAlert, | |
type: 'cep_error', | |
name: 'CEP_NOT_FOUND', | |
}); | |
} |
} | ||
|
||
// Processa o HTML para determinar restrições de entrega. | ||
const { errorDiv, positiveDiv } = parseCorreiosHtml(correiosData); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Na prática mesmo o que a gnt ta querendo aqui é baseado no html definir se a entrega é possível ou não, correto?
Será que não seria melhor essa função na vdd retornar um boolean e baseado nisso a gnt define a resposta?
Descrição da Nova Feature "Verificar Área de Risco dos Correios por CEP"
Implementamos uma nova funcionalidade no BrasilAPI que permite verificar se um CEP está localizado em uma área de risco, conforme classificado pelos Correios do Brasil. Esta feature é essencial para informar consumidores e empresas sobre restrições de entrega em determinados CEPs, reduzindo a incidência de surpresas desagradáveis e contribuindo para um planejamento mais eficaz de envios e recebimentos de encomendas.
Motivação
A motivação para o desenvolvimento desta funcionalidade surgiu da necessidade de mitigar os impactos da segregação social exacerbada pela falta de informação sobre áreas com restrição de entrega. Consumidores, especialmente em regiões periféricas, frequentemente enfrentam desafios ao receber encomendas devido a essas restrições, um problema pouco divulgado pelas empresas de distribuição. A transparência na verificação de CEPs em áreas de risco é também uma exigência do Código de Defesa do Consumidor brasileiro, reforçando a relevância desta funcionalidade.
Detalhes Técnicos
Benefícios para Empresas e Consumidores
Empresas de e-commerce, serviços de entrega, e consumidores se beneficiam diretamente desta funcionalidade. E-commerce, como a Magazine Luiza, poderá informar seus clientes antecipadamente sobre possíveis restrições de entrega em seus CEPs, aumentando a transparência e a satisfação do cliente. Serviços de entrega poderão planejar rotas mais eficientes, considerando as restrições existentes. Consumidores, por sua vez, estarão mais informados e poderão se planejar melhor para o recebimento de seus produtos.
Solicitação de Integração
Solicitamos a revisão desta implementação pela comunidade e a subsequente integração ao projeto principal do BrasilAPI, acreditando que esta funcionalidade agregará grande valor ao projeto e à sociedade brasileira.