APIs com Kotlin e Spring Data REST - parte 2

APIs com Kotlin e Spring Data REST - parte 2

Como vimos na parte 1 deste artigo, foi possível atingir o objetivo de minha colega Camila ao utilizar o Kotlin aliado ao Spring Data REST para a construção, quase que instantânea, de uma API no padrão REST. Contudo, a demanda dela fez com que um mergulho um pouco mais aprofundado nessa biblioteca fosse necessário, e é isso que vamos ver agora.

Padronizando a URL da API

Por padrão, ao criarmos os endpoints de nossa API, como visto no último artigo, o Spring Data REST cria URLs no padrão dominio/recurso-no-plural. Como estamos rodando a aplicação no domínio localhost:8080 e o único recurso criado é o da classe Instructor, temos ao final a URL localhost:8080/instructors sendo o endpoint base para esse recurso. Ou seja, a URL é construída com base no plural dos nomes das classes de nossos recursos. Isso tudo, graças à biblioteca Evo Inflector, que é utilizada por baixo dos panos. Contudo, uma coisa muito importante que precisa ser observada, é que ela é voltada para a língua inglesa! Caso seja necessário trabalhar com termos em português ou de outras línguas, uma saída é a utilização da anotação @RepositoryRestResource.

@RepositoryRestResource(path = "docentes")
interface DocenteRepository extends CrudRepository<Person, Long> {}

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.

# src/main/resources/application.properties

spring.data.rest.basePath=/api

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.

Banner da Escola de Programação: Matricula-se na escola de Programação. Junte-se a uma comunidade de mais de 500 mil estudantes. Na Alura você tem acesso a todos os cursos em uma única assinatura; tem novos lançamentos a cada semana; desafios práticos. Clique e saiba mais!

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.

interface InstructorRepository: CrudRepository<Instructor, Long> {

   @RestResource(exported = false)
   override fun deleteById(id: Long)

   @RestResource(exported = false)
   override fun delete(instructor: Instructor)

}

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

405 Method Not Allowed

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!

Gabriel Leite
Gabriel Leite

Gabriel é desenvolvedor e instrutor com foco em Java, Ionic e Node.js.

Veja outros artigos sobre Programação