2015-11-12 3 views
0

Я написал перехватчик, который после ошибки ответа, если код состояния и токен доступа присутствует в локальном хранилище, повторяет HTTP-запрос.Ускоренный повторный HTTP-перехватчик HTTP

Я написал это в основном, чтобы противостоять таинственным ошибкам ответов от используемого API (который я не контролирую), потому что в некоторых случаях достаточно повторения. Иногда конечная точка API терпит неудачу без причины, поэтому я решил, что, поскольку у меня нет контроля над обслуживанием API, я просто повторю отправку HTTP-запросов.

primesis.factory('httpResponseErrorInterceptor', function ($q, $injector) { 
    return { 
     'responseError': function (response) { 
      if(response.status === 500 && localStorage.getItem('token')) { 
       var $http = $injector.get('$http'); 
       return $http(response.config); 
      } 
      return $q.reject(response); 
     } 
    }; 
}); 

    $httpProvider.interceptors.push('httpResponseErrorInterceptor'); 

Однако, это приводит к бесконечно-перехватчик Повторная попытка в тех случаях, когда действительно есть ошибка в API.

То, что я пытаюсь достичь, - это установить предел в повторных попытках этого перехватчика. Я попытался положить в него счетчик, но похоже, что счетчик не переходит к следующему вызову перехватчика.

Я искал что-то, что касается такой ситуации, но безрезультатно. Есть ли способ установить ограничения на повторную попытку ответа на перехватчик?

ответ

2

@ Ответ csupnig будет работать, если вы можете представить его и написать для него реализацию, но мне удалось сделать это в пределах одного и того же самого перехватчика: никаких дополнительных услуг.

Вот как я это сделал:

app.factory('httpResponseErrorInterceptor', function ($q, $injector) { 
     return { 
      responseError: function (response) { 
       if(response.status === 500 && localStorage.getItem('token')) { 
       var $http = $injector.get('$http'); 

       if(response.config.Retries===undefined){ 
        //do something on first error e.g, reporting 
        response.config.Retries=1; 
        return $http(response.config); 
       }else{ 
        if(response.config.Retries!==2){ 
         response.config.Retries = response.config.Retries +1; 
         return $http(response.config); 
        } 
        else{ 
         response.config.Retries = undefined; 
         //do something on last retry 
         return $q.reject(response); 
        } 
       } 
      } 
      return $q.reject(response); // give up 
     } 
    }; 
}); 

Это работает путем присоединения счетчика на ответ конфиг себя.

Я признаю, что это может использовать некоторые рефакторинги, но вы получаете идею. Это сработало для моего случая использования, и я думаю, что это достаточно легко изменить.

0

Счетчик - это правильное решение, но вы должны поместить его в сервис, чтобы он перешел к следующему вызову перехватчика.

Я бы построил службу, которая управляет отображением запросов и попыток.

+0

Так вот в чем проблема! Правильно ли я полагаю, что эту услугу нужно будет вводить в перехватчик? Нужно ли мне создавать аксессуар и мутатор для счетчика? У меня возникли проблемы с попыткой визуализировать, как я связываю счетчики с их соответствующими запросами. –

+0

Да, вам нужно будет ввести службу в перехватчик, и да, вы должны создать аксессуар и мутатор для счетчика. Проблема в том, как вы отслеживаете запросы и их счетчики. Одна из возможностей заключается в хэшировании URL-адреса и параметров, но это приведет к тому, что аналогичные запросы также будут иметь один и тот же счетчик. Я бы предложил создать uuid, где вы делаете запросы, и использовать те же uuid для повторных попыток. Как только запрос будет успешным, вы должны очистить счетчик. – csupnig

+0

Теперь это становится яснее, но как я могу рассказать о повторных запросах, кроме новых? (так как я создавал UUID для новых и добавлял бы в счетчик для повторных попыток, но все еще не удалось). –