1
votes

Demander à l'API SpringBoot de renvoyer 200 avant le traitement

J'ai une API dont je ne veux pas que les gens puissent surveiller la durée de la demande xhr à l'API selon que le compte est valide ou non.

Le problème est que s'ils veulent récolter des identifiants d'utilisateurs, ils peuvent spammer l'API encore et encore et remarquer que les vrais identifiants mettent beaucoup plus de temps à renvoyer une réponse. La réponse est de 200 à chaque fois et la page ne fait rien avec la réponse.

Existe-t-il un moyen simple pour qu'une application Java SpringBoot renvoie immédiatement 200, puis effectue le traitement?


1 commentaires

Au fait, vous devriez vraiment utiliser 202 Accepted pour ce cas.


3 Réponses :


4
votes

Oui, vous pouvez le faire de manière asynchrone. Il vous suffit d'annoter la méthode de votre @Controller avec @Async . Cela rendra la méthode exécutée de manière asynchrone, de sorte que la connexion ne sera pas bloquée. Le proxy renvoie Future , plus d'informations peuvent être trouvées dans docs .


0 commentaires

1
votes

@Async est le moyen le plus simple.

Ajoutez l'annotation @EnableAsync dans votre classe principale (c'est-à-dire la classe principale avec l'annotation @SpringBootApplication )

Ajoutez @Async à votre méthode que vous vouliez exécuter dans un thread séparé.

Certaines limitations de @Async

  • il doit être appliqué aux méthodes publiques uniquement par auto-appel - appel
  • la méthode asynchrone de la même classe - ne fonctionnera pas

0 commentaires

1
votes

Alors que @async viendra à votre secours dans une situation comme celle-ci. Cela peut toujours être géré de manière très soignée.

  1. Essayez d'intercepter la demande dans un intercepteur / filtre qui vérifierait simplement la validité d'un compte et rejetterait les demandes appropriées sans qu'il atteigne le contrôleur.
  2. Sur le contrôleur invoquant une méthode de service asynchrone, n'oubliez pas de mentionner la taille du pool de threads principaux, la taille maximale du pool de threads, l'attribut de longueur de file d'attente, sinon le nombre de threads générés peut consommer toutes les ressources de la VM.
  3. / li>
  4. N'utilisez pas l'annotation @async sur une méthode transactionnelle imbriquée de référentiel car un @async avec @transactional gâche les transactions.

Vive!


0 commentaires