Должны ли иконки Twitter кэшироваться локально или иметь ссылку на URL, который возвращает API

Question

Когда я создавал свою первую кучу приложений Twitter, я писал код для локального кэширования пользовательских значков. В то время не казалось хорошей идеей предполагать, что эти значки всегда будут доступны в их исходных местоположениях. Это были сайты с относительно небольшим трафиком, и хотя я брал значки пользователей при входе в систему, это не сильно влияло на производительность. Ни один из них не передал эти значки пользователям моим посетителям.

Теперь, однако, я работаю над приложением, у которого значительно больше трафика, и мне интересно, могу ли я обойтись без горячей ссылки на URL-адреса, которые возвращает API Twitter. Это не кажется хорошей идеей, но большая часть (всего?) Кода приложения Twitter, на которую я смотрел, просто ссылается на изображения профиля. Может быть, это потому, что они в основном основаны на том же учебнике python-twitter auth , или, может быть, это потому, что их авторы знают то, чего я не знаю.

Если хорошей идеей будет просто установить горячую ссылку на значки, что произойдет, когда пользователь загрузит новый значок в Twitter и решит больше никогда не входить в мое приложение. Твиттер очищает свою старую иконку, которую я в какой-то момент удобно вставляю? В конце концов, это не непреодолимая проблема, но было бы хорошо узнать так или иначе.

Любая помощь, которую вы можете отправить, приветствуется.

Answer 1

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

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

Если ваше приложение является веб-приложением, я бы просто сделал ссылку на него.

Однако, если это не веб-приложение, и вы обнаруживаете, что производительность страдает от хотлинкинга, я бы сохранил список URL-адресов изображений профиля, сопоставленных с идентификаторами пользователей, а затем загрузил бы изображение и сохранил его, если вы этого не сделаете. его нет.

Затем, каждый раз, когда вы получаете информацию о пользователе, проверяйте URL-адрес, если он отличается от того, который у вас есть, загружайте контент снова и отображайте его (конечно, обновляя и вашу карту).

В некоторой связанной заметке помните, что общедоступная временная шкала кэшируется на 60 секунд , поэтому, если вы получаете оттуда информацию, вам не следует делать частоту выше этой *. 1017 *