Modern Web API Desgin

拥抱REST

现在，大部分主流网站都使用RESTful风格的API作为交互接口。REST几乎成了API的事实标准，无论是内部API还是外部API。这并不奇怪，因为REST的可伸缩性、可扩展性、低耦合等特性无疑是最适合做Web API不过了。

虽然各个网站API都标榜自己是REST，但从对REST的理解和实践上还有蛮多差别，我个人最欣赏的是Github V3的设计。

从Server-Side API 到 Client-Side API

先解释一下Server-Side API和Client-Side API:

• Server-Side API 主要指用户请求第三方服务器，第三方服务器再去调用API服务器这样的通讯方式。
• Client-Side API 与 Server-Side API 对应，指用户直接绕过第三方服务器，直接通过浏览器与API服务器交互。

Server-Side API 的缺点

• 调用者使用起来麻烦
• 需要大量的异常处理
• 容易堵塞第三方服务器
• 不容易利用缓存
• 不环保

Client-Side API的优点

• 使用方便，一般只需要引入一段JS
• 无需关心异常，因为浏览器有天然的容错机制，不会像服务器那样，一个异常就让整个请求挂掉
• API在浏览器里运行，不需要考虑超时处理、进程堵塞等一系列问题
• 浏览器是最强大的HTTP客户端，自带各种缓存机制
• 数据从用户浏览器直接发送到API服务器，不需要经过任何中间层。

现有的 Client-Side API

• Twitter Follow Button
• Twitter Tweet Button
• Google +1 Button
• Google Analytics
• Facebook Like Button
• Disqus Comments
• Stripe Payment Button

上面的功能各异，从关注、发推、评论到统计甚至支付。实现方式各异，从最简单的JSONP形式到动态IFrame，但都把复杂留给了API服务提供端，把方便留个了API调用者。在处理跨域问题上有很多技术难点，但Client-Side API相比Server-Side API在给开发者带来的体验是有了质的飞越。

Client-Side API Over Server-Side API

我的观点是，一个和需要用户交互的API服务，如果能设计成Client-Side就不要设计成Server-Side的。

关于安全

不懂安全的人喜欢把一个东西设计的很麻烦来让人觉得这是安全的，典型的例子是支付宝。

JSONP作为跨域Client-Side API的最主要方式，在传输敏感数据会有JSONP Leak漏洞，但是也可以通过per-sign的方式避免的。

甚至像Amazon S3图片上传这样的功能也可以做成Client-Side的，并且很安全。

第三方服务器通过生成一个用secret key预签名的表单，用户直接从浏览器把图片传到S3服务器，S3服务器成功接收图片之后callback给第三方服务器。但是由于S3不能在云端对图片进行缩放等处理，遇到需要将一张图片生成不同尺寸图片这种需求会麻烦些。不过七牛做的就比较完美了，不但支持客户端直传图片，而且支持云端图片处理。