Fallback en cas d'échec de l'API transitoire

4

J'essaie de trouver le meilleur moyen de résoudre un problème que j'ai avec des API tierces (OG, Foursquare, Yelp, etc.). J'utilise l'API transitoire pour appeler et stocker les différentes données afin de:

  1. Ne pas dépasser les limites de l'API
  2. Augmenter la vitesse de chargement

Toutefois, le problème se pose lorsqu'un nouvel appel d'API est erroné , quelle qu'en soit la raison; soit il y avait un problème avec la connexion, soit l'API elle-même était en panne (hello foursquare). Cela conduit à un scénario dans lequel vous n'avez pas de nouvelles données et dont les anciennes données ont expiré (ce qui est essentiellement ce qui a déclenché la génération d'un nouveau transitoire). Comment gérez-vous de telles situations?

La solution à laquelle je pense consiste à créer une option statique dans la fonction d'actualisation qui stocke une réponse réussie ou affiche la dernière réponse réussie après une erreur, par exemple:

<?php

function refresh_api_data() {

... perform API call ...

if ( $response->status == 'error' ) {
     $response = get_option( 'fallback_data' );
} else {
     update_option( 'fallback_data', $response );
}

return $response;

}

?>

Cela a-t-il un sens ou quelqu'un a-t-il une solution plus élégante à l'esprit?

Merci!

    
posée Noel Tock 24.01.2012 - 00:08

3 réponses

5

Mark Jaquith a créé une méthode "TLC Transitoires" qui pourrait vous être utile. Pour l’essentiel, il implémente une interface transitoire permettant l’expiration logicielle et la mise à jour en arrière-plan.

enlace

L’idée est de définir une fonction pour effectuer l’appel qui récupère les données, puis de définir le transitoire et de lui transmettre cette fonction en tant que rappel. Lorsque vous passez cet appel, il récupérera les données si nécessaire et les renverra dans un transitoire pendant la période définie. La mise à jour "logicielle" signifie qu'elle renvoie toujours les données mises en cache immédiatement et entraîne la mise à jour après coup, en arrière-plan (à l'aide d'un travail wp-cron).

Cela présenterait également l'avantage de toujours renvoyer les "anciennes" données jusqu'à la réussite de la mise à jour. La façon dont cela est traité par son code consiste à faire en sorte que votre fonction de rappel lève une exception si la récupération des données échoue pour une raison quelconque.

    
réponse donnée Otto 24.01.2012 - 06:43
1

Vous pouvez définir un autre transitoire en cas de succès avec un long délai d'attente. Ensuite, si le premier arrive à échéance et que vous obtenez une erreur, votre sauvegarde sera transitoire. En cas de succès, les deux transitoires sont mis à jour.

Comme votre idée, je pense que vous pouvez aller dans les deux sens.

    
réponse donnée Rob Vermeer 24.01.2012 - 00:19
0

J'ai tendance à faire ce qui suit:

1) Générez les données sur un événement ou une planification dorsal. Le transitoire est configuré pour durer BEAUCOUP plus longtemps que je ne m'attendrais à ce qu'il soit actualisé. J'ai également "sauvegardé" les données en utilisant add_option tout en réglant l'option de ne pas charger automatiquement. Si l'appel d'API échoue, je ne redéfinis pas les données et les anciennes données ne sont pas touchées.

2) À l'écran, vérifiez s'il y a du transitoire. Si le transitoire existe, affichez-le. Sinon, extrayez-la de l'option, affichez-la, puis remettez-la en cache pour que les futures demandes soient extraites de l'antémémoire. J'utilise cette méthode car parfois, dans les environnements memcached, les transitoires sont expulsés. Plutôt que d'exécuter à nouveau la requête lourde, je peux extraire les données de l'option.

    
réponse donnée tollmanz 24.01.2012 - 05:37

Lire d'autres questions sur les étiquettes