Personnalisation des points de terminaison HTTP dans REST Spring Data

Personnalisation des points de terminaison HTTP dans REST Spring Data

1. introduction

Spring Data REST peut supprimer un grand nombre de passe-partout qui sont naturels pour les services REST.

Dans ce didacticiel, nous allons découvrir commentcustomize some of Spring Data REST’s HTTP binding defaults.

2. Principes de base du référentiel REST de Spring Data

Pour commencer, nous allonscreate an empty interface that extends the CrudRepository interface, en spécifiant le type de notre entité et le type de sa clé primaire:

public interface UserRepository extends CrudRepository {}

Par défaut,Spring generates all the mappings needed, configure chaque ressource pour être accessible via les méthodes HTTP appropriées, et renvoie les codes d'état appropriés.

Si nous n’avons pas besoin de toutes les ressources définies dansCrudRepository, nous pouvons étendre l’interface de base deRepository etdefine only the resources we want:

public interface UserRepository extends Repository {
  void deleteById(Long aLong);
}

À la réception d'une requête,Spring reads the HTTP Method used and, depending on the resource type, calls the appropriate method defined in our interface, s'il est présent, ou renvoie un état HTTP405 (Method Not Allowed) dans le cas contraire.

En référence au code ci-dessus, lorsque Spring reçoit une requête DELETE, il exécute notre méthodedeleteById.

3. Restreindre les méthodes HTTP exposées

Imaginons que nous ayons un système de gestion des utilisateurs. On pourrait alors avoir unUserRepository.

Et, puisque nous utilisons Spring Data REST, nous en tirons beaucoup à étendreCrudRepository:

@RepositoryRestResource(collectionResourceRel = "users", path = "users")
public interface UserRepository extends CrudRepository {}

All our resources are exposed using the default CRUD pattern, donc émettant la commande suivante:

curl -v -X DELETE http://localhost:8080/users/

renverra un état HTTP204 (No Content returned) pour confirmer la suppression.

Maintenant, supposonswe want to hide the delete method de tiers tout en pouvant l’utiliser en interne.

Nous pouvons ensuite ajouter d'abord la signature de la méthodedeleteById dans notre interface, qui signale à Spring Data REST que nous allons la configurer.

Ensuite, nous pouvons utiliser l'annotation@RestResource(exported = false), qui seraconfigure Spring to skip this method when triggering the HTTP method exposure:

@Override
@RestResource(exported = false)
void deleteById(Long aLong);

Maintenant, si nous répétons la même commandecUrl ci-dessus, nous recevrons un état HTTP405 (Method Not Allowed) à la place.

4. Personnalisation des méthodes HTTP prises en charge

L'annotation@RestResource nous donne également la possibilité decustomize the URL path mapped to a repository method et de l'ID de lien dans le JSON renvoyé par la découverte de ressourcesHATEOAS.

Pour cela, nous utilisons les paramètres optionnels de l'annotation:

  • path pour le chemin de l'URL

  • rel  pour l'ID de lien

Revenons à nosUserRepository et ajoutons une méthode simplefindByEmail:

WebsiteUser findByEmail(@Param("email") String email);

En exécutant uncUrl vershttp://localhost:8080/users/search/, nous pouvons maintenant voir notre nouvelle méthode listée avec d'autres ressources:

{
  "_links": {
    "findByEmail": {
      "href": "http://localhost:8080/users/search/findByEmail{?email}"
    },
    "self": {
      "href": "http://localhost:8080/users/search/"
    }
  }
}

If we don’t like the default path, instead of changing the repository method, we can simply add the @RestResource annotation:

@RestResource(path = "byEmail", rel = "customFindMethod")
WebsiteUser findByEmail(@Param("email") String email);

Et si nous effectuons à nouveau la découverte des ressources, le JSON résultant confirmera nos modifications:

{
  "_links": {
    "customFindMethod": {
      "href": "http://localhost:8080/users/search/byEmail{?email}",
      "templated": true
    },
    "self": {
      "href": "http://localhost:8080/users/search/"
    }
  }
}

5. Configuration programmatique

Parfois, nous avons besoin d’un niveau de configuration plus fin pour exposer ou restreindre l’accès à nos méthodes HTTP. Par exemple, POST sur les ressources de collection, ainsi que PUT et PATCH sur les ressources d'élément, utilisent tous la même méthodesave.

Starting from Spring Data REST 3.1, and available with Spring Boot 2.1,we can change the exposure of a specific HTTP method via la classeExposureConfiguration . Cette classe de configuration particulière expose une API basée sur lambda pour définir des règles globales et basées sur des types.

Par exemple, nous pouvons utiliserExposureConfiguration pour restreindre les requêtes PATCH par rapport auxUserRepository:

public class RestConfig implements RepositoryRestConfigurer {
    @Override
    public void configureRepositoryRestConfiguration(RepositoryRestConfiguration restConfig) {
        ExposureConfiguration config = restConfig.getExposureConfiguration();
        config.forDomainType(WebsiteUser.class).withItemExposure((metadata, httpMethods) ->
          httpMethods.disable(HttpMethod.PATCH));
    }
}

6. Conclusion

Dans cet article, nous avons expliqué comment nous pouvons configurer Spring Data REST pour personnaliser les méthodes HTTP prises en charge par défaut dans nos ressources.

Comme d'habitude, les exemples utilisés dans cet article se trouvent dans nosGitHub project.