语盒在推送邮件之后，就在其他莓友的帮助下使用了新浪微博进行宣传，和用户的交流。后来发现，使用已有的长连接通道，可以推送任何信息，那么为何不进行一下微博的推送呢？当然，在1.0版本之后就进行了微博推送的开发。那时语盒还叫 yuchberry。

在经过这么就的开发过程之后，接触了有新浪微博、腾讯微博、推特微博（邪恶的也叫它微博），实在忍不住想从技术上说些东西，然后做一个比较。因为做技术的人，总是想拿什么东西比较一下，才无私无畏地觉得自己“博大精深”，“贯通史今”，以便抚慰被众多bug打击的快不行了的幼小软弱的心灵。

申请授权

地球人都知道，天下微博源自推，而推的开放API以及API访问的方法OAuth，国内大多数微博也都照瓢画葫芦的弄了过来。具体技术不想多讲了，说说一般流程，首先你得申请一个应用，新浪和腾讯微博差不多，他们都有开放平台([1],[2])，基本上都能使用一个普通的微博号，然后申请应用。不同的是，推特申请后，直接全功能，不需要啥审核，直接就上，新浪需要你设置测试账号，供你测试，然后和腾讯一样需要人工审核，当然是审核你的应用链接地址，确认不是一个很黄很暴力的应用。

这个很让我纠结，推特所谓的API是什么目的呢？我经常看到有人发推——来自“春天里”，来自“奶瓶嘴”，来自“火星”，搞得我云里雾里的，或许，推特就是让人们用很多的API来表达自己的态度。相反，国内的微博API使用则更多是基于商业目的，使用API来派生出更多的商业模式，大家把满足用户需求把所谓蛋糕做大——一起吃，而用户只要点点就行了，猜个星座，搞个竞拍，转发有奖啥的。那如果搞起基来，肯定相当具有杀伤力，于是人工审查，就成了必须的一道小门槛。

API  SDK

所谓的API，就是让你通过一定的规则去获得、改变一个系统的内部数据，当然做的越简单越好，但是网络API本身就基于HTTP协议，无法做到易用安全并重，所以一般的API都会提供一个中间层进行访问。语盒是使用Java开发的服务器，所以必然要找Java的SDK。好吧，说一说这个Java SDK的故事。

首先有了推特，推特API发布，于是有了推特4j（其官网已被墙认证），而且是开源的，好吧，我发现新浪也有了API，名字和推特的API名字很像，也有了weibo4j，怎么看怎么像，weibo4j的注释有些都挺像的。

再来看看腾讯微博的API接口样式：

腾讯微博的Java SDK 在我开发的时候做的较弱一些，但是在我写这篇文章的时候，他们已经发布了一个更加完善的版本，大概阅读了这些代码，的确完成的较多了，可是从设计的角度来说，窃以为没有语盒那部分写的好，原因是他们的版本基本上没有封装、隐藏实现的中间层作用，而且没有基本的参数判断，作为一个库，不判断上层传入的参数是否基本合法，弹出异常让开发者尽快排查数据，就直接进入请求阶段，和没库差不多。

扯远了，三者比较起来大概是下面这个关系：!推<–新浪 | 腾讯?

调用次数限制

腾讯的应用开发者获得API调用次数我觉得是最多的，同IP请求80000次每小时，单账户能够达到1000+次每小时，新浪也不少，也差不多能够达到这个数量，可怜的推特，只有每小时350次的限度。

从这个也是看出，腾讯财大气粗，服务器实例雄厚，即便业务上做不好，后台肯定是刚刚滴；新浪面对众多商业应用，限额给的也很好，对API限制划分得也很细。推特只有总数，而且限额很少，面对的，还是是用户自己表达方式不同，可能一个用户使用多个应用发布自己的推——在不同的环境下。

私信

我不知道为何新浪对私信的控制权这么强烈，推特直接可以访问，腾讯也在审核之后直接访问，这使得新浪所谓的API开放并非做到了100%，在网页的私信聊天的演变来看，隐隐觉得新浪的野心不光是维护好、发展好一个SNS产品这么简单了。

我曾经发信给新浪的API帮助。一般来说审核相关的问题回复的最快，其他技术其次，但是私信的API授权询问邮件直接石沉大海——没了，搞什么灰机？！

总结

其实也没有什么好总结的，都是形式差不多的短消息社会化分享评论机制，但是一边做的各路英雄逐鹿，商业模式辈出；一边是小资情调，单一、自由地分享。无论是什么样的市场催生什么产品，还是什么样的产品促成什么样的市场，都无法完全说明其中变化的原因。这里只是比较一下，从技术的角度，竟然得出了商业的结果，看来以“经济建设为中心”的原则已经完全的深入人心了。