开放API好用么? 对于一个小团队来说...

开放的API是个好东西:

从Google,Facebook,Twitter 到国内的各种SNS,微博站点,  它们中的绝大部分都有一套基于HTTP＋XML/JSON的开放API。靠这些开放API, 一个简单的手机客户端也能做很多事情，如果配合自己的服务器程序,   开发者很快就可以推出一套低成本的客户端＋网络服务。首先感谢这些开发API提供者, 不过我也想想说说我的看法:

先忆苦思甜，和早期的Webservice， SOAP XML 这些重型HTTP API比较，现在主流的解决方案:HTTP＋JSON，已经是非常轻便好用了.  不知道还有没有人记得拿JBuilder自动生成Webservice代码的的时候,  我想只有靠代码行数拿工资的程序员才会怀念那些日子。

但是，现在的开放API还是有不少改进的空间， 我至少遇到了一些问题:

第一个问题：没有区分第三方客户端和服务器两个完全不同的环境。比如认证登录这块，采用Oauth是为了不让第三方站点获取到用户密码, 通过web界面登录再跳转.  对第三方web服务器是合适的。但是对客户端，我觉得这样是多此一举。使用WebView容易丢失焦点， 界面loading延迟， 而且也无法真正防止恶意客户端偷偷获取账号/密码。 这样的结果是什么呢？  最好的客户端都是不用Oauth的直接走特殊认证的。 如果一个API设计的结果是第三方要靠绕过它显示自己技术或者商务谈判或者用户体验牛逼。  那么可以认为这个API的适用范围需要调整了。

第二个问题是， API的往往是按照服务自身逻辑完整性设计的， 而不是按照使用案例设计的， 一个糟糕的例子如下，显示最近朋友的更新，需要先获取朋友列表ID， 然后获取每个朋友个人信息， 然后获取每个朋友产生的文字内容。  这不是调用3次API的问题， 这是调用1+2/*N次API的问题。

第三个问题:  客户端代码跑后台线程是受限的, 很多API给出的资源都是单独的URL。 如果很多零零碎碎的小图片需要同屏幕显示，而手机又存在手机和WIFI两种速度差别很大的网络，客户端需要大量的代码来处理异步读取和错误处理(请考虑可能还有几个网站API要同时支持). 而且这段代码维护起来也很痛苦. (这个时候在server写一个页面, 然后在客户端直接用Webview显示是个不错的办法)

最后一个问题:  更新！ 在服务器上更新， 废弃一个API是非常快的事情。 但是客户端上就慢多了，客户端不同的版本共存则是常事。 如果开放API做了不兼容的修改, 老的客户端就完全不可用了. 如果你使用了些第三方API的封装库而它没有更新，你会更痛苦。我们的做法是在服务器有一整套proxy api server， 客户端尽可能和自己的API打交道， 把对开放API的支持放到Server上做，这样倒是能解决问题。但是我觉得从专业分工的角度上看， 不是每个客户端团队都有应该做这样的事情。

那么我们该怎么做呢?

如果是你客户端开发者, 隔离,封装是必要的, 如果可能, 尽量把开放API放到Server上支持,保持客户端的简单. (另外离那些非官方的API封装包远远的！）如果你是服务器程序员,  真心希望你可以尝试一下客户端网络编程,比如iPhone和Android. 这样能帮助你设计出更好的API. 毕竟: 你总需要用用自己设计的东西嘛.