Есть веб-сервис, работа с которым организована следующим образом.
Перед началом работ необходимо запросить с сервиса токен доступа. Токен доступа действует несколько часов.
После того, как токен доступа получен, у сервиса можно вызывать определенные методы.
Если метод по какой-либо причине выполнить нельзя, то возвращается ошибка; в том числе ошибка будет возвращена при использовании недействительного токена.
По умолчанию токен действует 6 часов, у меня токен кешируется на 4 часа, чтобы повторный получать досрочно.
Но иногда на сервере текущие токены сбрасываются, и тогда закешированные токены становятся недействующими досрочно.
Метода проверки токена на сервисе не предусмотрено, о недействительном токене можно узнать только если попробовать с его помощью вызвать какой-либо метод.
Структурно взаимодействие с сервисом сделано так:


Методы сервиса доступны как методы классов (метод auth и прочие), которые в свою очередь вызывают внутренний метод http.
Сейчас внутри http обрабатывается специфичная ошибка и в случае просроченного токена он запрашивается повторно и http повторяется.
Или лучше проверку и повтор вынести во внешние методы (которые будут анализировать результат http и в случае просроченного токена получать новый и повторять запрос)?

Разница в том, что в одном случае вызов http выполняется рекурсивно, в другом случае во внешнем цикле.
Есть ли тут какая-то заметная разница?

Дегтярев Евгенийв методе проверки нет никакого смысла, т.к. результат имеет смысл только на момент вызова метода, нет гарантии, что валидный, в один момент, токен не протухнет к моменту вызова след метода.
Смысл вполне практичный — упростить обработку вызова и ошибок.
Это как валидация полей формы на клиенте — на сервере это все-равно проверяется, но дополнительный контроль на клиенте сделает это более удобным и понятным для пользователя. В случае с веб-сервисом пользователем является мой скрипт.

Дегтярев Евгенийя бы не стал смешивать логику вызова и логику потора и вынес ее повыше.
Да, аргумент.

vkleЛогически же получается в некотором смысле непорядочек. Если правильно понимаю, рекурсия тут не нужна, достаточно запустить повторно curl_exec() с новым токеном.
Да, если упростить, то именно так.

Дегтярев Евгениймежду вызовом метода проверки, который скаал - ок, и следующим вызовом метода, токен может протухнуть, а следовательно проверки на предмет ошибок невалидного токена никуда не денуться
Упрощение в том, что подобная ситуация будет маловероятной и проверка будет намного проще — вместо запроса нового токена и повтора запроса будет просто фиксироваться сбой метода.

Редактировать нельзя, поэтому поясню в отдельном сообщении.
Ранее алгоритм работы скрипта был следующий:
1. Скрипт получает токен из кеша и проверяет срок его действия (по умолчанию токен действует 6 часов с момента получения).
2. Если срок истек, то скрипт получает новый токен и кеширует его.
3. Затем используя полученный токен (из кеша или новый) скрипт вызывает метод веб-сервиса.
Если по какой-то причине токен завершил свое действие досрочно (например на сервере сбросили все токены), то скрипт пропускает пункт 2, а на пункте 3 при попытке выполнения метода фиксирует в логе ошибку. Первоначально предполагалось, что подобный досрочный сброс токенов это ситуация исключительно редкая, поэтому подобные ошибки будут обрабатываться вручную.
Но оказалось, что они возникают достаточно часто (минимум раз в неделю), поэтому и пришлось эту ситуацию автоматизировать.
Если бы у веб-сервиса был метод, позволяющий проверить валидность токена (или срок его действия), то можно было бы вернуться к предыдущей схеме — между проверкой токена и вызовом метода проходят секунды и вероятность сброса токена в этом периоде была бы крайне малой. И соответственно, ввиду редкости подобного события никакой специальной обработки программировать бы не пришлось, в логе бы просто фиксировался сбой вызова метода с последующим ручным разбором причин.