Personalizar endpoints con @RestResource

En estos momentos tenemos un servicio HATEOAS que puede ser descubierto navegando por sus enlaces desde el raíz. Sin embargo sólo hemos configurado las propiedades de @RepositoryRestResource. En nuestras aplicación probablemente querremos poder personalizar alguna URL (sobretodo de los métodos que nos hacemos con query methods de JPA), no permitir algunas operaciones (por ejemplo no dejar borrar un participante) o al menos no permitirlas para todos los usuarios (sólo podrá borrar el adminitrador).

Vamos a ver cómo personalizar algunos de estos aspectos utilizando la anotación @RestResource.

En ParticipanteDAO voy poner las siguientes líneas:

@RestResource(path="nombre")
List<Participante> findByNombreIgnoreCaseContaining(String txt);

@RestResource(exported=false)
void deleteById(String id);

@RestResource(exported=false)
void delete(Participante entity);

// Mejor ponerselo a todo lo que tenga que aplicarse
// void deleteAll(Iterable<? extends Participante> entities);
// ...

Estas líneas hacen dos cosas:

1. Modifica la URL para que el fragmento del path del primer método sea nombre.
2. Prohibe el uso de DELETE sobre Participantes.

NOTA: JpaRepository tiene 6 distintos métodos de borrado, formalmente y por rendimiento es mejor aplicar la anotación a todos ellos aunque con uno sólo sería suficiente. Aquí se indica pero no se ha hecho para ahorrar código.

Ahora quiero buscar un Partido donde participe un idParticipante que le pase. Pongo esta línea en PartidoDAO:

@RestResource(path="participante")
List<PartidoConId> findByIdLocalOrIdVisitante(@Param("idParticipante") String idLocal, @Param("idParticipante") String idVisitante);

Aquí utilizo además la anotación @Param. Esta anotación me permite enlazar un query parameter de la petición HTTP a un parámetro de mi método. La sintaxis del query method de JPA me va a obligar a tener tantos parámetros como vea que necesita su nombre (idLocal e idVisitante). Sin embargo puedo enlazar el mismo query parameter a los dos parámetros.

Puedo encontrar estos enlaces en el path /search de cada recurso.

Puedes encontrar el código hasta aquí en su repositorio.

Esta entrada es muy corta pero ya se puede practicar mucho con ella. Propongo hacer los siguientes métodos de búsqueda y ponerles el nombre apropiado:

1. Buscar sucesos por id de Participante
2. Buscar sucesos entre un Instant comienzo y otro fin
3. Buscar sucesos para un idParticipante entre comienzo y fin. Este método no se expondrá en la API.
4. Buscar sucesos después de un Instant instant. El query param tendrá el nombre start.

La solución está en github.