Retorno quando a API temporária falha

4

Estou tentando descobrir a melhor forma de resolver um problema que tenho com APIs de terceiros (OG, Foursquare, Yelp etc.). Eu uso a API transitória para chamar e armazenar os vários dados para:

  1. Não ultrapasse os limites da API
  2. Aumentar a velocidade de carregamento

No entanto, o problema surge quando um novo erro de chamada da API é para qualquer que seja o motivo; ou houve um problema com a conexão ou a própria API estava inativa (ola foursquare). Isso leva a um cenário em que você não tem dados novos e os dados antigos expiraram (o que é essencialmente o que acionou um novo transiente a ser gerado). Como você lida com tais situações?

A solução que tenho em mente é criar uma opção estática dentro da função de atualização que armazena uma resposta bem-sucedida ou exibe a última resposta bem-sucedida em um erro, por exemplo:

<?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;

}

?>

Isso faz sentido ou alguém tem uma solução mais elegante em mente?

Obrigado!

    
por Noel Tock 24.01.2012 / 00:08

3 respostas

5

Mark Jaquith fez um método "TLC Transients" que você pode achar útil. Essencialmente, ele implementa uma interface temporária que faz a expiração temporária e a atualização em segundo plano.

enlace

A idéia é que você defina uma função para fazer a chamada que obtém os dados, defina o transiente e passe essa função como um retorno de chamada. Quando você fizer essa chamada, ela obterá os dados, se necessário, e os retornará, armazenando-os em um transiente durante o período de tempo definido. A atualização "soft" significa que ela sempre retorna os dados em cache imediatamente e faz com que a atualização ocorra após o fato, em segundo plano (usando uma tarefa wp-cron).

Isso também teria a vantagem de sempre retornar os dados "antigos" até que ocorra uma atualização bem-sucedida. A maneira como isso é tratado por seu código é que você faz com que sua função de retorno de chamada lance uma exceção se a recuperação dos dados for malsucedida por qualquer motivo.

    
por Otto 24.01.2012 / 06:43
1

Você pode definir outro transiente em sucesso com um tempo limite longo. Então, se o primeiro expirar e você receber um erro, você terá seu transiente de backup. Se houver sucesso, ambos os transientes serão atualizados.

É semelhante à sua ideia, então acho que você pode ir de qualquer forma.

    
por Rob Vermeer 24.01.2012 / 00:19
0

Eu costumo fazer o seguinte:

1) Gere os dados em um evento ou cronograma de back-end. O transitório está definido para durar MUITO mais do que o esperado para ser atualizado. Eu também "backup" dos dados usando add_option , definindo a opção para não carregar automaticamente. Se a API chamar erros, simplesmente não configurarei os dados novamente e os dados antigos não serão tocados.

2) Na exibição, verifique se há transiente. Se o transiente existir, exiba-o. Caso contrário, puxe-o da opção, exiba-o e coloque-o de volta no cache para que as solicitações futuras sejam retiradas do cache. Eu uso esse método porque às vezes em ambientes memcached, os transientes são despejados. Em vez de executar a solicitação pesada novamente, posso extrair os dados da opção.

    
por tollmanz 24.01.2012 / 05:37