REST on Rails指南2：无穷尽的API

通过上一讲，我认为你树立了这个概念：即Web其实是一组资源而不是网页的集合（如果你还不这么认为，那请你先返回再次阅读第一讲）。这一讲我们将从另一个侧面来讲解为什么要有REST？

面向对象设计与分析

如果你曾经学习过面向对象程序设计，那么你很可能会这样开始构建你的新程序：

• 首先，你需要定义你的问题域——你的程序要解决什么问题
• 然后，你会定义一个类，这个类的名字一般是名词
• 接着你会为这个类定义一些方法，方法的名字一般是动词
• 最用，通过调用其它类的方法，你的这个类顺利完成了它的使命

这看起来不错，事实上我曾经这么干了好多年，这种名词加动词的编程方法被成为“RPC”（远程过程调用），虽然我不明白那个Remote（远程）是指什么，但RPC的确是构建面向对象软件的一个重要方法，不过这种方式却并不适合Web开发。

让我们回到远古，假设现在是1992年（或者Web出现之前的随便什么日子），假设有这样的三家公司，他们需要开发这样三种应用：书籍贩卖，机票贩 卖以及 卫星地图浏览。并且他们都遵照了面向对象的设计思想，同时出于长远考虑，他们都认为总有一天会有第三方的软件需要同他们的系统进行交互，因此，他们都实现 了他们各自的API。

现在，假设你的老板分配给你一个任务：为这三个系统设计一个统一的前端，你会怎么做呢？

我想你首先需要学习这三种完全不同的API，然后为每一个API设计一个UI控件，当用户操作UI控件时，对应的API就会被调用，你可能会通过你学到的一些设计模式知识来简化你的工作量，并使你的代码看起来尽可能酷一些。

无穷尽的API

当然这只是假设，但即使真的如此，在Web时代，你也不需要去学习那些无穷尽的糟糕API，你所要做的就是在你的电脑上安装一个浏览器，不是吗？浏 览器对 于你将要访问的网站一无所知，但它却能够准确的返回你想要的，你可以通过它购买音乐，预定机票，甚至从任意远的距离来欣赏你家的屋顶。

这很神奇，不是吗？但是让我们设想一下，如果每个网站都有它们自己的API会是什么样子？如果你想在Amazon买本书，浏览器必须知道如何调用 Amazong.buy()，如果你想查看航班信息，那么浏览器需要知道如何调用UnitedAirlines.CheckFlights()，事实上， 这样通吃所有API的程序永远也不可能被开发出来。

所以这就决定了Web不可能是RPC式的，它只能是REST式的。

以资源为中心的设计

那么REST究竟是什么呢？按照维基百科的解释，REST是指Representational State Transfer。这是什么意思呢，简单的说，就是现在每个名词都不再拥有它们各自独一无二的动词了，在REST的世界里，所有名词拥有的动词都是一样 的，并且数量也很有限。换句话说，也就是所有的资源都提供了一组相同的API，这些API的实质就是允许随便什么客户端：

• 获取资源的某种表示
• 创建一个新资源
• 更新已存在的资源
• 销毁一个资源

等一下！那么究竟上面那个API可以让我“购买一本书”呢？搜索“下周二从纽约飞往洛杉矶的航班”又是哪个API完成的呢？

我们将在下一讲回答这个问题，但是如果你已经改变思维，不再认为”买书“就是一个网页，而是开始思考这其实是某个资源的创建，那么我想你其实应该已经知道答案了。