“未分类”目录存档

分析一下新浪微博API目前的问题

2010年08月22日,星期天

新浪微博在今年上半年的时候开始了开放平台的内测,我烧网作为国内知名的博客阅读社区有幸成为其最初的合作网站,并根据自身需要通过OAuth方式模拟出了类似“人人连接”(人人Connect)的“新浪微博连接”。新浪微博用户可以直接通过微博帐号登录我烧网,无需二次注册。在代码编写和功能测试过程中,我们得到了新浪微博同仁们大力的支持与耐心的指导,在此我深表谢意。

当然,新浪微博开放平台还处于初创阶段,很多问题尚未推敲周全。我最近在编写同步功能的时候就深深体会到了这一点,也就此机会探讨一下问题和可能的解决方案。

1.Access Token永久有效

作为合作网站,我们当然希望用最少的代码完成最多的功能。如果Access Token有时效性,我们就需要使用更多的代码来进行有效性验证。因此,Access Token永久有效让合作网站的开发工作变得十分容易了。但是对于用户来讲就不那么乐观了。也许有些初级用户抱着试试看的态度授权了某个应用,之后就不想再使用了,永久有效的授权就意味着即使这个用户不再使用这个应用,应用本身也可以假借用户本人进行操作。也许你会说:将应用授权取消掉不就行了?然而,我们的大部分用户都是非常初级的用户,他们或许永远无法理解什么叫做“应用授权”,那么他们也就永远无法进行“取消授权”的操作。

不过,对于这个问题,确实是没有什么好的解决方案。如果按照类似Session Key的方式进行处理,就意味着超时过后,应用本身需要用户再次授权。而这对某些异步操作几乎是不可能的(以我烧网为例,同步叨叨到新浪微博的代码会被封装为一个异步的扩展类。但是我们需要在真正执行这部分代码的时候才会知道Access Token是否过期,而且如果真的过期的话,由于这部分代码是异步代码,我们根本就无法让用户再次授权。)。比较折中的方案就是,在授权界面上,给用户留两个选项“长期使用”和“我只是来逛逛”,默认是“我只是来逛逛”。“长期使用”就是像现在这样永久有效的授权,“我只是来逛逛”就只授权24小时。这样可以在一定程度上解决之前提到的问题。

2.授权取消

最近在编写代码的时候,我们发现无论用谁提供的代码(新浪、OAuth、我们自己编写的)都无法成功进行update操作(发布微博信息),新浪微博API永远返回400错误(source parameter(appkey) is missing)。我们知道,使用OAuth访问API是不需要source参数的。这可能是新浪微博API的一种判断机制:如果OAuth验证失败就尝试使用基本验证。因此我们就尝试提供source参数,API马上给我们返回403错误(auth failed)。我们一度认为是我们对OAuth方式POST数据不太理解,为此还查阅了大量的资料,阅读了大量的范例代码,无果。后来重新注册一个新的帐号并且授权我烧网之后,一切问题都不存在了。由此我们意识到很有可能是我们最初使用的Access Token已经取消授权了。那为什么新浪微博没有给予我们这部分通知呢?

Access Token的生命周期,在新浪微博那边应该是非常完整的,只不过没有完整的体现在API上罢了。这部分解决方案主要有两种:回调通知和返回过期状态。

回调通知:就是在用户取消授权的同时,新浪微博访问应用的某个URL,通知应用该用户已经取消了授权,Access Token即时失效。这需要应用开发者在配置应用的时候填写相应的回调地址,而且这不适用于桌面应用。

返回过期状态:就是应用在进行操作的时候,如果Access Token失效,就不要单纯的返回403错误。而是详细的返回如403-1(Access Token过期)、403-2(用户已取消授权)等信息,这样应用可以根据返回值自动更新用户的授权状态,自我完善Access Token的生命周期。

以上观点均出自作者本人,与我烧网无关。

加入我烧网

2009年12月17日,星期四

今后大家可以通过我烧网了解我的博客以及我的最新动态。我的我烧网主页是http://woshao.com/Timandes/。欢迎大家关注我!

认证码:8cf3dc776a84d44020a56a07352b4676

把RSS加入了我烧网

2009年11月20日,星期五

我已正式把我的RSS加入我烧网,我的认证字符串为(acc9f9e7ccc7cd4e4b515baeb3c7b29b),大家现在也可以通过我烧网实时了解我最新更新的文章了。

把RSS加入了我烧网

2009年08月13日,星期四

我已正式把我的RSS加入我烧网,我的认证字符串为(9a681b2748b9f917ca242161099f4508),大家现在也可以通过我烧叨叨实时了解我最新更新的文章了。

FriendFeed如何使用MySQL存储无Schema数据(三)

2009年06月15日,星期一

一致性和原子性

由于我们给数据库做过分片,并且实体的索引可以被存储在和它本身不同的多个分片之上,这样一致性就成了问题。要是进程在完成对所有索引表的写入前就崩溃了,那该如何是好?

(全文…)

FriendFeed如何使用MySQL存储无Schema数据(二)

2009年06月11日,星期四

详细内容

实体在MySQL存储在类似下面的表中:

CREATE TABLE entities (

added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,

id BINARY(16) NOT NULL,

updated TIMESTAMP NOT NULL,

body MEDIUMBLOB,

UNIQUE KEY(id),

KEY(updated)

) ENGINE = InnoDB;

(全文…)

FriendFeed如何使用MySQL存储无Schema数据(一)

2009年06月10日,星期三

背景

在FriendFeed中,我们使用MySL存储所有的数据。随着用户数量的增加,数据库也在不断增长。目前,我们的存储条目数量已经超过了2.5亿,除此之外还有大量的其他数据,包括评论和喜好以及朋友列表等。

随着数据库的增长,我们不得不一而再、再而三的处理飞速成长所带来的伸缩性问题。常见的手法,我们都有过实践,例如使用只读从数据库和memcache来提高读吞吐量,以及对数据库进行分片,从而提高写入吞吐量。然而,随着技术的不断发展,通过扩展已有功能来承载更高流量所带来的问题和增加新功能相比,已经是小巫见大巫了。

(全文…)

加快头像读取速度

2009年06月6日,星期六

在头像使用极为频繁的网站上,将头像缓存起来是一种节省Web及IO资源的有效途径。一般的做法是使用反向代理软件,比如Squid。

但是,无语用户如何更换头像,头像的文件名却是确定的,比如head_48×48.jpg。这样就与Squid的缓存机制产生了冲突,总不能要求每个更换了头像的用户都等48小时后才能看到自己的新头像吧?^_^

(全文…)

头像文件的处理与保存

2009年06月6日,星期六

一般来说,头像文件是各种以用户为中心的网站必须要处理的。建站初期,头像文件大多以

http://www.xxx.com/heads/1.jpg

的形式保存,xxx.com代表网站的域名,1.jpg代表用户ID为1的用户的头像。这样做的坏处显而易见,当用户数量超过heads目录能够有效保存的文件数量极限的时候,对于头像的存取将及其缓慢。所有的操作系统都有directory下file数量的限制,即使头像数量达不到这个极限,也会大大影响存取效率。

(全文…)

随机文章的缓存优化

2009年06月2日,星期二

带有随机性展示的文章历来不被网站设计人员喜爱,原因主要在于实现的难度和优化机制的设计。理论上来说,随机性展示的文章列表是不可能进行优化的。但是实际上,很多网站都使用相对短一些的缓存过期时间来尽可能解决随机性与优化之间的矛盾。使用这种方式,访问者在10s(甚至更短的时间)之内,看到的随机文章列表的内容是完全一样的。最近考虑到一种方法,在不缩短缓存过期时间的情况下,使访问者在缓存过期时间之内随机看到更多的文章。

(全文…)