1.4.1 仓库保管员的窘境

小刚是一名仓库保管员，每天要处理几千人次的物品领取工作，读者觉得辛勤的小刚会喜欢下面请求的哪一种呢？

A.领物品A258，我要200个。

B.还要昨天我领的那种，但我今天多要100个。

先来考虑一下选项B，因为这个选项显得更人性化。为了实现这个人性化的请求方式，需要记得这个客人昨天领过什么以及领了多少，这要求保管员小刚有惊人的记忆力，用计算机术语来说，就是内存要很大。但超常的记忆力并不能解决以下两个问题：

● 如果哪一天小刚休假了，临时顶替小刚的保管员没有小刚的记忆，又如何知道这个客户的“老规矩”呢？

● 如果这个仓库不止小刚一个保管员，那这个老客户每次都必须要小刚来服务，因为别的保管员没有小刚的记忆。但如果小刚的十个老客户一起来了，那他们就要排队等小刚服务，别的保管员完全帮不上忙。

有的读者会想，小刚可以把这些记在小本子上啊。这其实是一个非常可行的办法，可记录和查找这条记录都需要额外的时间，还存在出错的可能性。而且如果仓库扩容了，增加到100个保管员，那是每个保管员都要有一个小本子，还是大家共享一个小本子呢？

● 如果每一个人都有一个小本子，每一次记录都要同时扩散到100个本子上，这也是个额外的消耗。每次新增加一个保管员，就需要增加一个小本子，复制所有数据到新的小本子上也需要花时间。

● 如果大家共享一个小本子，那当同时处理多个客户请求的时候，这个小本子就成了大家争抢的焦点，非常容易成为系统的瓶颈。

再来看选项A，显然面对这样的请求，小刚就不需要去记忆客户以往的行为了，也不需要什么小本子。而且小刚有个头痛脑热的时候想请假也方便了，其他保管员很容易顶替小刚，提供和小刚一模一样的服务。每当逢年过节，突然有非常多的人一起来领物品，也只需要多派几个保管员来服务就好了。但是对于选项A，所有的客户需要遵守请求的规范，每次领取物品的时候，需要“整齐划一”地提供保管员所要的信息，这样小刚就不需要为每个客户去记忆不必要的信息了。

服务器和保管员小刚非常类似，就是在干类似仓库保管员的工作，把保管员的记忆力映射成服务器的内存，小本子映射成数据库，很多突发的故障就好像人会生病，逢年过节就会迎来访问高峰等。于是，服务器和仓库保管员一样，都会更喜欢选项A这样的请求。针对选项A这种服务器端/客户端互动的方式，计算机科学家们给出了一个绕口的专业名词——表述性状态迁移，也就是REST（Representational State Transfer），而基于这种方式设计出来的API，称作RESTful API，而提供RESTful API的服务，一般称为RESTful服务。