周末用了下新微博开攑^台API和官方发布的Java客户端,感觉可以用两个字形容Q坑爹!
先说说遇到的几个极其弱智的bug吧:
1Q分?/p>
官方API文档里面Ҏ据分获取的说明是用cursor和countq两个参数。其中,cursor指明了v始记录的位置Q而count指明了当前每늚记录条数Q请求第一늚时候cursor?1。返回结果会l出next_cursorQ指明下一늚起始位置?/p>
q个设计看v来不错,问题是根据这个文档,得到的结果会有重复。也是说同一条记录会出现在多个页面中Q而且q种重复出现的频率是随机的。试惌E序的行为都无法预测Q叫别h怎么开发应用?Q?/p>
更搞W的是,官方发布的Java客户端居然把cursor写成了pageQ导致了不管怎么讄参数Q返回的都是很多重复的数据,但重复的比例又是随机的!N新浪没有对这个客Lq行q简单的试发布了吗?无法惌Q!
2Q返回结果的解析
好不Ҏ把用户信息得CQ新自己写了一个JavaBean用来表示一个User的信息。问题是把JSON解析成Java对象的时候,居然把布属性字D解析错了,D每次q回都是falseQ好不容易得到的数据p么汤了~~N解析JSON很难嘛?Q敢试下再发布吗?
3Q诡异的负数
我小学学到的知识告诉我,人的个数不可能是负数。于是我天真的在followers_countq个数据库字D上加了unsignedQ本以ؓ教数据库的老师应该很开心吧Q这孩子设计的数据库q蛮严}的,而且应该能够和新的数据很好地匹配?/p>
于是我开心的q行E序Q诡异的错误出现了:出字段范围。晕Q于是检查所有数字字D|否超q了表示范围QN遍检查过后确认数据库没问题,U结~~于是看logQ发现返回的数据里面Q有一个项的followers_cout字段?2Q负敎ͼQ!玛qh虽然_丝了点,也不至于Ơ你新浪两个_丝吧,我当时就凌ؕ了,于是加了很多异常数据的判断和查。。?/p>
4Q诡异的版权信息
Java客户端里面很多文件的作者信息是Q@author Yusuke Yamamoto - yusuke at mac.comQ感觉这应该是一个苹果公司的员工开发的Q然后新拿q来Q没有code reviewQ没有测试,q接官方发布了。。?/p>
q样不重视代码质量,把品构建在志愿者的贡献之上Q我觉得是新的耻iQ更是中国互联网产业的顽症恶疾?/p>
以上只是我这两天试用了一部分API的感受。由于各UbugQ我不得不阅L代码QƈҎ我的需求改写代码,甚至一度我准备抛弃q个客户端,直接用HTTP调用。反正最后严重降低了我的效率?br />