Slim Framework — Criando Microservices 05— Validações e Exceptions na API

Fala galera! Hoje vamos falar e implementar um processo de validações e e exceptions dentro do nosso serviço de CRUD de livros.

Até o post anterior, nós criamos todas as operações de CRUD via REST da nossa API, porém deixamos algumas pontas soltas e sem nenhuma validação de entrada e saída dos nossos pacotes de dados.

Caso tenha caído de paraquedas nesse artigo, recomendo que leia a evolução da arquitetura da nossa aplicação até aqui.

Ativando Debug Mode do Slim

Por Default o Slim bloqueia toda a exibição de erros para o usuário, entregando uma página de erro genérica em text/html, mesmo via as requisições em JSON e XML.

Para ativar a entrega de erros transparente, precisamos criar uma array de configurações do Slim e colocá-los dentro do nosso Container de dependências, coisa que acompanhamos nos últimos artigos.

bootstrap.php

Com isso todos os detalhes dos erros serão exibidos para o usuário. Ainda não é o ideal, mas vamos melhorar isso até o final da sua leitura.

Validações nos Setters das nossas Entidades.

Vamos primeiramente estabelecer o mínimo de validações possíveis dentro das nossas entidades, no caso, nossa única até agora, chamada Book. 
Vamos aplicar as validações dentro dos Setters da entidade, impedindo que sejam inseridos valores nulos nos campos obrigatórios, como Name e Author. Basicamente vamos verificar se o Input que foi passado para nosso dois Setters chave foram valores Null e caso seja, irá chamar um Exception dentro da aplicação e parar a execução.

src/Models/Entity/Book.php

$ curl -X POST http://localhost:8000/book -H "Content-type: application/json" -i

E um request vazio vai nos devolver uma página de erro do Slim com um Backtrace simplificado em HTML. Não queremos isso agora…

Retornando as Exceptions e Codes via JSON para o Cliente

Para criarmos uma API de respeito, precisamos dar na mão do usuário todos os possíveis erros que poderiam ocorrer, com os Status Codes adequados para que ele possa trabalhar e tratar na parte de responsabilidade dele quando for consumir nosso serviço. Vamos criar uma chave dentro do nosso container chamada ‘errorHandler’, e atribuir a ela uma função que trata nosso erro, criando um objeto de response devolvendo uma mensagem no formato JSON e o Status Code com o código que lançamos nos nossos Exceptions da aplicação.

Logo, sempre que lançarmos uma exception do tipo

throw new \Exception("Exception de Teste", 503);

Será devolvido para o usuário um JSON parecido com:

{
"message" : "Exception de Teste"
}
HTTP/1.1 503 Service Unavailable

Nosso bootstrap.php ficou da seguinte forma após as alterações:

bootstrap.php

Validando erros nas Rotas

Para fazer a validação das rotas, vamos fazer o mínimo possível também. Vamos verificar todas as rotas que procuram por uma entidade informada pelo ID para ser exibida ou manipulada e validar se aquela entidade realmente existe no nosso banco de dados.

Basicamente vamos retornar se o nosso Find do Entity Manager retorna a entidade prometida ou não, caso não encontre, lançaremos uma Exception com o Status Code 404 (Not Found) que será convertido para o usuário.

Nosso index.php ficará assim:

index.php

Agora nossos Requests com ID’s e parâmetros inválidos vão disparar Exceptions, transformar nossas Mensagens de Erros e Error Codes em JSON Responses e interromper nossa operação. Agora evoluímos nossa aplicação um pouco mais. Agora nossos inputs não são mais aceitos as cegas e nossas entidades possuem algumas travas na hora da manipulação. Ainda vamos evoluir isso logo mais.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.