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=/apiAssim, 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.
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 AllowedNesse 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!
