APIs com Kotlin e Spring Data REST - parte 2

Dessa forma, conseguiríamos uma URL como localhost:8080/docentes utilizando o termo corretamente no plural e na língua portuguesa.

Ainda assim, um outro detalhe importante a se observar, é que geralmente, utilizamos uma URL raiz para as APIs, como localhost:8080/api, a partir da qual, acrescentamos o caminho do recurso que queremos acessar. E esse, é justamente o passo que minha colega gostaria de dar, tendo como principal motivo o fato de que no endereço localhost:8080 estaria rodando a aplicação Front-End que consumiria a API em desenvolvimento.

E a boa notícia é que tal objetivo é bem simples de se atingir! Graças a boa organização do Spring Data REST, tudo que precisamos, é lançar mão de uma configuração chamada spring.data.rest.basePath. Ela é a responsável por indicar a base da URL utilizada para a API. Bastando assim, que seja feito algo, como visto a seguir, no arquivo de propriedades da aplicação.

Assim, se voltarmos a executar a nossa aplicação, veremos que todas as URLs, tanto de requisição, quanto de resposta, já irão considerar o endereço localhost:8080/api como a raiz de nossa aplicação REST.

Customizando as operações

Por fim, mas não menos importante, a última necessidade de minha colega era a remoção da operação de deleção. Ou seja, era necessário que a API não atendesse requisições do verbo DELETE para o endereço localhost:8080/api/instructors/id-do-recurso já que a intenção era que tivéssemos sempre um histórico das informações desse recurso em questão.

Para resolvermos essa situação, basta lembrarmos que podemos sobrescrever o comportamento dos métodos definidos pela interface CrudRepository<T, ID>. Dando uma olhada na documentação, vemos que temos os métodos delete() e deleteById(), sendo ambos responsáveis por deletar uma única instância do recurso. Sendo assim, tudo que precisamos fazer é sobrescrevê-los enquanto informamos à nossa aplicação que não queremos torná-los públicos na nossa API por meio da anotação @RestResource com a opção exported = false.

E agora, ao fazermos uma requisição DELETE obtemos a resposta a seguir:

Nesse ponto, uma observação extremamente importante! Para que o verbo DELETE deixe de ser atendido como queremos, é obrigatória a sobrescrita de ambos os métodos! Como visto na documentação ocorre que o algoritmo usado por baixo dos panos pelo Spring não permite que excluamos apenas um dos métodos de deleção, forçando assim, a exclusão de ambos.

Assim, consegui mostrar à minha colega, a efetividade na utilização do Spring Data REST aliado ao Kotlin e a deixei muito entusiasmada para continuar tocando o projeto em frente!

E você, o que achou? Gostaria de ver novos conteúdos de Kotlin aplicados ao Back-End? Deixe seu comentário e até a próxima!