在第六章里，我们通过构建我们自己的 API 了解到了设计 API 同时了解了一些真实的例子。此外，我们拥有了很多难以获得的知识，现在我们可以有所成效了。我们已经准备好见证如何让 API 为我们工作了。在这个章节里，我们学习 4 种通过 API 实现实时通信的方法。
让我们更加容易讨谈，先让我们回忆一下为什么 API 有用？回顾第一章，我们说 APIs 让我们在两个系统之间（网页、电脑、智能手机）分享数据变得轻松。简洁的分享让我们可以把系统连接在一起形成一个集成。因为集成让人们生活变得很轻松，所以人们都很喜欢集成。使用集成，你在某一系统上做一些事情，其他系统可以自动更新同步。
为了我们的目的，我们将集成分成两个目录，首先，我们先了解“客户驱动”，人们想要影响客户端，并且相让服务端的数据更新。另一个我们称为“服务端驱动”，当人们在服务器有所改变，需要让客户端了解改变的情况。
用这种方式划分集成的原因是一个简单的事实：客户端是唯一能启动通信的。请记住，客户端发出请求，服务端只是回应。这种限制的后果就是，改变可以容易的从客户端发到服务端，但是很难从服务端发到客户端。
为了演示为什么客户驱动的集成很容易，让我们回到之前谈及的披萨店和订餐的 API 。说一个我们发布的使用 API 的手机 app 。在这之中，披萨店的 API 就是服务端，手机 app 就是客户端。一个顾客使用 app 选择了一个披萨，并且点击按钮发送订单。当按钮一被按，app 就知道它需要向披萨店的 API 发送请求了。
通俗地说，当一个人和客户端进行交互的时候，客户端就知道数据什么时候改变了，所以它能即可寻求 API 让服务端知道。没有一点延时（因此它是实时的）并且这个过程十分高效，只因为人发出的唯一一个请求。
当披萨订单被提交，顾客可能就想知道披萨什么时候好。我们如何通过 API 提供给他们这种更新呢？这有一点难。顾客不会做任何事对于制作披萨。他们只会在披萨店等待准备披萨并且更新订单的状态。换言之，当数据正在改变在服务端上，客户端需要知道他们。但是，如果我客户端不能发出请求，我们就卡住了。
解决这种问题的办法就是我们利用第二种集成目录。有需要的软件开发者想出各种解决办法克服只有客户端请求的限制。让我们了解一下。
轮询
尽管客户端是唯一个可以发送请求的，但最简单的解决办法就是保持服务端的更新，当客户端需要服务端更新的时候。这种可以通过反复请求相同资源来完成，称为轮询。
当我们的披萨店，轮询一个订单的状态可能和以下相同：
用这种方法，客户端发送请求越频繁，客户端越接近实时通信。如果客户端没一个小时轮询，最差的结果是，这会有一个小时的延迟，当服务端发生改变的时候，客户端才察觉。每分钟都轮询，服务端可以有效地保持同步。
当然，这种方式有一个巨大的缺陷。这是非常低效的。大部分客户端发送的请求都被浪费了，因为没有任何的改变。更糟糕的是，为了更快的更新，轮询的间隔需要很短，为了让客户端发送更多的请求，所以变得越来越低效。这个办法很难扩展。
长轮询
如果请求是免费的，没有人会在意效率问，而且每个人都会使用轮询。但是不幸的是，处理请求需要一定代价。对于一个 请求更多请求的 API ，它需要使用更多的服务，需要花更多的钱。这种繁琐程度可以达到 Google 和 Facebook 的大小比例，而且你付出了很多低效率的事情。因此，大量的工夫都投入到优化这种方法，客户端从服务端获得更新。
从轮询中得到优化，称为长轮询。长轮询使用的同样思路，客户端反复询问服务端更新，但是不同的是：服务端不会立刻回应。相反，当服务端发生了改变以后，才会回应更新。
让我们回忆一下轮询的例子，但是这次是服务端使用一个长轮询。
这种技术非常聪明。它遵循客户端初始请求的规则，借助不存在反对服务端缓慢回应的规则。只要客户端和服务端同意，服务端可以持着客户端的请求，并且客户端能够保持和服务端的连接，它就工作了。
长轮询是非常智能的，它也有一些缺点。我们跳跃了技术细节，但是这会有一些关注，有多少请求服务端可以同时持有，或则如果服务端和客户端断开了连接，如何恢复？现在，我们会说在某些情况下，轮询的方式也不够用了。
网络挂接
当轮询被排除，一些创新的软件开发者想，“如果所有的问题都源于客户端是唯一一个可以发出请求的，为什么不移除这个规则？”正如他所说。这种结果就是网络挂接（webhocks），一种技术，客户端可以发送请求并且听取他们，让服务端可以轻松的推送更新给它。
如果这个听起来像是欺骗，因为我们让服务端发送请求给客户端，不用担心，你没有被骗。让客户端也变成服务端可以让网络挂接工作。透视这个技术，有时它可以轻易的扩展客户端，让它也能够听到请求，启用两种通信方式。
让我们看一下网络挂接的基础。用最简单的形式，网络挂接需要客户端提供一个 Callback URL（回拨 URL ），能够接受事件，并且服务端有一个地方让人可以进入 Callback。之后，一旦服务端有什么改变，服务端将发送一个请求到客户端的 Callback URL ，让客户端知道更新。
对比我们的披萨店，流程可能看起来像下面这样。
这个解决办法是非常好的。改变在服务端一发生就被发送到客户端，所以你拥有真正的实时通信。此外，网络挂接也是非常高效的，因为每次更新只有一个请求。
订阅网络挂接
在网络挂接的基础上， 涌现出大量的解决办法针对让建立进程变得动态并且不需要人手动进入 Callback URL 在服务端。你可能听到过，HTTP 订阅规范，Restful Webhooks, REST Hooks , and PubSubHubbub 。所有这些解决办法都是尝试确定一个订阅进程，客户端告诉服务端它感兴趣什么事件，Callback URL 发送什么更新。
每一种方案都略有不同再解决问题上，但是大概的流程和以下一样。
基于订阅的网络挂接持有很多承诺。他们是高效的，实时的，并且人们可以轻易使用。类似 REST 被采用，一个浪潮正在崛起，并且变得越来越普通，对于 API 支持一些网络挂接的形式。
仍然，在未来，这会有一部分属于轮询和长轮询。不是所有的客户端能够和客户端一样行动。智能手机就是最好的例子，技术上的限制排除了网络挂接的方法。随着技术的进步，新的方法会出现，对于如何让实时通信变得更轻松在所有设备间。
在这个章节里，我们将集成分成了两个目录，客户端驱动，服务端驱动。我们了解在两个系统之间， API 如何提供实现更新，并且存在的一些问题。
关键点：
Poling（轮询）：反复请求资源在极短时间内
Long Poling（长轮询）：轮询，但是回应延迟；提高了效率
Webhooks（网络挂接）：当客户端给服务端一个 Callback URL，服务端能够实时提供更新
Subscription Webhooks（订阅网络挂接）：为了让网络挂接自动的非正式解决方案名称
