APIs com Kotlin e Spring Data REST: parte 1

Eu expliquei que uma boa vantagem do Kotlin é ser uma linguagem que roda na JVM e completamente interoperável com o Java. Portanto, estando apta a se valer de todo o ecossistema criado para esta linguagem.

Assim, minha sugestão foi de utilizar o Spring Data REST para a criação rápida da API! Dando uma rápida olhada na página inicial da documentação 1, veremos que o Spring Data REST é parte integrante do projeto Sprint Data e tem como principais características:

• Expõe uma API REST detectável para seu modelo de domínio usando HAL como um tipo de mídia.
• Expõe recursos de coleção, item e associação, que representam seu modelo.
• Atualmente, suporta JPA, MongoDB, Neo4j, Solr, Cassandra, Gemfire.
• Permite personalizações avançadas dos recursos padrões expostos.

Dentre outros. Mas de todas essas características, a que mais se destaca é a facilidade na exposição de recursos baseados nas classes de modelo da aplicação. Um detalhe importante é que o Spring Data REST é fortemente baseado na JSON Hypertext Application Language ( HAL ). O HAL é uma padronização para tráfego de informações que está em desenvolvimento e visa, basicamente, criar uma representação da informação baseada em links que possibilitem a navegação e descobrimento de novas informações.

Contudo, o nosso foco é a API que queremos desenvolver! Sendo assim, apenas a título de teste, criei com a Camila, um projeto no Spring Initializr com as configurações a seguir.

Observem a biblioteca Rest Repositories. Ela será a responsável por nos ajudar em nossa tarefa. Após baixar o projeto e importação para sua IDE favorita, podemos colocar a mão na massa!

Expondo os recursos da API

Para começar, disse à Camila que precisaremos criar um modelo de dados da nossa aplicação. Isso é fácil e já estamos bem acostumados, portanto, criamos uma classe Instructors no pacote br.com.alura.instructorsapi.model com os atributos necessários.

Não há nada de novo aqui, apenas o bom e velho JPA sendo configurado através de suas anotações.

O grande pulo do gato vem agora! Após configurar nosso modelo, queremos expor endpoints para as principais operações do CRUD da forma mais rápida possível! E é aí que o Spring Data REST entra, e nos possibilita fazer algo como:

Nós criamos uma interface InstructorRepository que estende de CrudRepository<T, ID>, interface que pertence ao Spring Data REST e que é a responsável por identificar o modelo de dados a partir do tipo genérico T e criar todos os endpoints necessários para as operações de CRUD, dentre outros detalhes. Como em nosso caso, o tipo genérico T foi definido como Instructor, os endpoints foram criados para o nosso modelo de dados. Antes de testar tudo, o último passo importante é indicar que por padrão, a nossa aplicação trabalhará com JSON. Essa configuração é feita no arquivo application.properties, adicionando a linha a seguir.

Feito isso, podemos executar a aplicação e em seguida efetuar requisições para a nossa API! Simples assim!

Sendo assim, utilizando o cURL, poderíamos enviar algumas requisições de cadastro, como visto a seguir:

Que resultariam em respostas parecidas com essa:

Por fim, após alguns cadastros, para verificar que as operações ocorreram com sucesso, podemos listar os dados cadastrados em nossa API.

Após essa jornada, minha colega ficou extremamente animada com a novidade e com a rapidez do desenvolvimento. Mas logo em seguida, ela me revelou com um pouco de apreensão, que precisaria fazer algumas alterações, dentre as quais: padronizar a URL da API com o prefixo /api, não permitir que requisições com o verbo DELETE sejam recebidas e outras mais.

Eu respondi que após uma pausa eu lhe ajudaria a dar um mergulho mais profundo no Spring Data REST para entender alguns detalhes que, por baixo dos panos, iriam permitir que ela chegasse aos objetivos dela. Esse relato vocês podem encontrar na parte 2 deste artigo.