web-dev-qa-db-fra.com

Quelles erreurs HTTP ne doivent jamais déclencher une nouvelle tentative automatique?

J'essaie de rendre quelques microservices plus résilients et réessayer certains types de requêtes HTTP aiderait à cela.

Les délais d'attente de nouvelle tentative donneront aux clients une expérience terriblement lente, donc je n'ai pas l'intention de réessayer dans ce cas. Réessayer 400s n'aide pas car une mauvaise requête restera une mauvaise requête quelques millisecondes plus tard.

J'imagine qu'il y a d'autres raisons de ne pas réessayer quelques autres types d'erreurs, mais quelles erreurs et pourquoi?

httpmicroserviceshttpresponsehystrixspring-retry
15
cahen

Certaines erreurs ne doivent pas être réessayées car elles semblent permanentes:

  • 400 Mauvaise demande
  • 401 non autorisé
  • 402 Paiement requis
  • 403 Interdit
  • 405 Méthode non autorisée
  • 406 Non acceptable
  • Authentification proxy 407 requise
  • 409 Conflit - cela dépend
  • 410 disparu
  • 411 Longueur requise
  • Échec de la condition préalable 412
  • 413 Charge utile trop importante
  • 414 URI trop long
  • 415 Type de support non pris en charge
  • 416 Portée insatisfaisante
  • Échec de l'attente 417
  • 418 Je suis une théière - pas sûr de celle-ci
  • 421 Demande mal acheminée
  • 422 Entité non traitable
  • 423 Verrouillé - cela dépend de la durée moyenne de verrouillage d'une ressource (?)
  • 424 Dépendance défaillante
  • 426 Mise à niveau requise - le client peut-il être mis à niveau automatiquement?
  • 428 Condition préalable requise - Je ne pense pas que la condition préalable puisse être remplie la deuxième fois sans se retirer du début de l'ensemble du processus, mais cela dépend
  • 429 Trop de demandes - cela dépend mais il ne faut pas réessayer de jeûner
  • 431 Demander trop de champs d'en-tête
  • 451 non disponible pour des raisons juridiques

Par conséquent, la plupart des erreurs client 4 ** ne doivent pas être réessayées.

Les erreurs des 5 ** serveurs qui ne doivent pas être réessayées:

  • 500 Erreur de serveur interne
  • 501 non implémenté
  • 502 Bad Gateway - J'ai vu utilisé pour des erreurs temporaires donc cela dépend
  • Version 505 HTTP non prise en charge
  • La variante 506 négocie également
  • 507 Stockage insuffisant
  • 508 boucle détectée
  • 510 non étendu
  • 511 Authentification réseau requise

Cependant, afin de rendre les microservices plus résilients, vous devez utiliser le modèle Disjoncteur et échouer rapidement lorsque l'amont est en panne.

12
Constantin Galbenu

Les codes 4xx signifient qu'une erreur a été commise du côté de l'appelant. Cela peut être une mauvaise URL, de mauvaises informations d'authentification ou tout ce qui indique qu'il s'agit d'une mauvaise demande. Par conséquent, sans résoudre ce problème, il n'est pas nécessaire de réessayer. L'erreur se trouve dans le domaine de l'appelant et l'appelant doit le corriger au lieu d'espérer qu'il se réparera lui-même.

Il y a des exceptions. Imaginons que le service soit redéployé ou redémarré. À cette instance, il n'y a pas de point de terminaison enregistré et donc enverra le code http 4xx. Cependant, un instant plus tard, le serveur pourrait être disponible. Une nouvelle tentative peut donc sembler bénéfique.

Une analyse plus approfondie indiquera qu'un service, lorsqu'il est redémarré, devrait être un redémarrage continu pour éviter les pannes. Par conséquent, l'argument précédent n'est plus vrai. Cependant, si votre environnement/écosystème ne suit pas cette pratique et que vous pensez que les erreurs signalées côté client (codes 4xx) valent la peine d'être réessayées pour la raison susmentionnée, vous pouvez choisir de le faire; mais les systèmes matures ne le feront pas en raison de l'absence d'avantages perçus et de la perte de la capacité d'échec rapide.

Les codes d'erreur 5xx doivent être réessayés car il s'agit d'erreurs de service. Ils peuvent être à court terme (threads débordants, service dépendant refusant les connexions) ou à long terme (défaut du système, panne du système dépendant, infrastructure indisponible). Parfois, les services répondent avec des informations (souvent des en-têtes), qu'elles soient permanentes ou temporaires; et parfois un paramètre de temps pour savoir quand réessayer. En fonction de ces paramètres, les appelants peuvent choisir de réessayer ou non.

Les codes 1xx, 2xx et 3xx n'ont pas besoin d'être retentés pour des raisons évidentes.

4
ArinBhat