在您的应用中,在正常业务需要的情况下,尽量减少请求量,减少请求接口返回数据,有必要缓存一些已经获取到的数据,来提高应用的效率和体验。下面一些场景,可供参考:
获取/statuses/friends_timeline(用户首页)
1. 第一次请求后,缓存下请求内容
2. 下一次刷新的时候使用since_id(值为前一次请求的最大微博id)来获取更新
获取/statuses/followers(用户粉丝)
1. 第一次请求后,缓存下请求内容
2. 当获取/statuses/unread接口有新粉丝的时候,则重新获取,没有则不变更
3. 完成后调用/statuses/reset_count来清除消息提醒
获取/direct_messages(用户私信)
1. 第一次请求后,缓存下请求内容
2. 当获取/statuses/unread接口有新私信的时候,则重新获取,没有则不变更
3. 完成后调用/statuses/reset_count来清除消息提醒
获取/statuses/mentions(用户提到)
1. 第一次请求后,缓存下请求内容
2. 当获取/statuses/unread接口有新粉丝的时候,则重新获取,没有则不变更
3. 完成后调用/statuses/reset_count来清除消息提醒
对很少变动的数据缓存
1. 用户昵称,头像很少更改,可对用户昵称,头像做一个较长的缓存
2. 表情数据很少更改,可以缓存一个很长的缓存
如何避免rate limit微博开放平台会对每个应用的用户有一个频率限制,怎样来让用户的操作不达到频率限制呢?下面有一个简单的样例,参考下:
1. 确定哪些需要定时访问的接口,每个接口做一个优先级,访问的频率做为一个变量
2. 计算下一定要访问的接口数据量
3. 预留给用户一定的更新(发微博,私信等)
4. 使用Account/rate_limit_status查看当前appkey所能支持的每小时的最大访问量,根据此访问量来确定频率的值