网络历史上曾有过一段黑暗的时期。在服务有API之前。谢天谢地，这段时间已经过去了。每个人都认识到需要为客户提供对服务。如果你的服务只有少数客户在使用你的API，他们可能不会产生太多的负载。很有可能您不会强制实施API限制。聪明的企业至少会有一些基本的机制，以便在一夜之间失控的情况下实施API限制成功。希望如此您的服务发展到需要API限制的成功水平。现在你开始收到客户的请求（或者你以前有过这些请求）。在API限制之前，客户可以反复轮询您的API，看看有什么变化。那些重复的轮询是粗鲁的客户端，但它们的编写和调试也非常简单。解决方案似乎很明显，将责任倒置：当情况发生变化时，API将调用客户。WebHooks、events、callback等，我们称它们为什么并不重要，事实上，它们是我们用来删除重复轮询器并减少API负载的解决方案模式服务。如果我们要为服务api定义一个成熟度模型，企业交流软件，它可能看起来像这个：我们有阿皮尤可以用我们的阿皮尤做任何事需要知道我们的限制我们有网络挂钩，但我认为我们不应该就此止步。我认为至少还有一个更高的层次，不幸的是，我还没有看到很多服务api处于这个级别。一个类比可能救命啊派对问题我们正在举办一个盛大的派对-想象一下那些奥斯卡派对。客人来了去吧。我们提供一个API来告诉你谁在派对上。交易是在这些聚会上达成的，如果威尔·史密斯根本不在，就没必要在聚会上推销他。见鬼，如果斯嘉丽·约翰森已经走了，那么她就没必要再呆在派对上听你的剧本了。所以我们提供/api/v1/attenting/{name}让您检查此人是否在那里。这是一级。我们有一个API，可以满足一些大的支付需求顾客。在那里想知道谁是我们的API的客户。好吧，所以流言蜚语是一个有点阴暗的行业，大淘客网，但他们是付钱给顾客的。。。名人们其实需要关注。我们不能一直拥有它们跑步：为了名字单位：美元（cat名人.txt)；做卷曲$name&&echo$name>>与会者金融机构别担心它会淹没我们的服务器名人.txt档案缺少了吸引大牌人物加入我们党的热血。所以我们提供了/api/v1/attendees，它返回了聚会中所有人的列表。这是2级。你知道我们有很多高频交易者在使用我们的API吗？似乎他们正在使用机器学习来关联聚会参与者，云服务器服务，并尝试预测将达成哪些电影交易，以推动各个电影制片厂的投资决策！谁知道？但是，是的，我们将不得不对我们的API设置速率限制，因为他们绝对是在敲打它。这是3级。没有人对API的限制感到满意。在詹妮弗·劳伦斯到达派对后马上等待入场时间的媒体大亨们已经习惯了一边跑一边跑！卷曲+Lawrence；睡觉1其他人基本上都习惯了打人尽可能的频繁和快速地竞争。所以我们介绍一个WebHook API。媒体大亨们只需订阅他们感兴趣的一两个人，他们一到或离开我们就给他们打电话。其他所有人都可以订阅完整的事件流，以便在每个人到达和离开时收到通知。这是第4级。现在，作为API的用户，如果我们想知道与会者的变化，我们有一个选择：我们可以定期获取所有与会者的列表，并手动关联自上次投票以来的增量；或者我们可以订阅但是，WebHook如果我们想知道在任何时候谁在派对上呢？如果WebHook是可靠的，如果我们的WebHook接收器有100%的正常运行时间，如果两者之间的网络总是可用的，那么我们就可以从已知的起点开始工作，并将增量应用到名单。但是这些事情不是百分之百真实的。他们可能大部分是正确的，但是1%或0.1%或0.01%的情况经常发生，我们需要采取一些方法来纠正它。那个天真的解决方案是定期调用与会者列表API。但是，如果我们的请求同时发生了WebHook事件，会发生什么呢？询问当前与会者名单Cruise arrivesEmma Watson离开我们得到与会者名单我们应该把Tom Cruise加入我们的与会者名单吗？还是把他带走？关于艾玛·沃森离开的事件呢？如果她不在我们最初的与会者名单中呢？我们甚至还没有把与会者名单包括在交易的与会者名单中，因为我们还没有把与会者名单包括在交易的后台定期出席调用与会者列表API并不是在制造事情更简单。也许吧重复是关键。我们认为变化的速度太快了，无法确保我们的列表在任何时间点都是100%准确的，但我们希望确保我们在某种合理的范围内弥合事件差距时间。如果我们连续调用与会者API两次，并比较两个列表。在这两个列表中出现的任何人都肯定是在提出第一个请求和收到第二个响应之间的某个时间出现的。没有出现在这两个名单上的人肯定在某个时候不在那个窗口。这给了我们两个可以更正的列表申请。什么如果party attendees API包含一些机制来帮助客户机协调两个API路径之间的内部状态，则会更好。这是第5级。服务API成熟度模型（SAMM）1级："我们有一个API"API的特点是功能缺陷，购物返利平台，可能是由一两个通过功能有效设计API的大客户的需求驱动的请求。级别2： "你可以用我们的API做任何事情"API现在已经足够强大了您可以避免使用服务UI，而只需与API交互。如果存在使用限制，则限制足够高，大多数客户可以有效地忽略他们。水平3： "您需要了解我们的限制"服务和API通常是成功的，因此，限制已经降低到影响最大的程度客户。级别4： "我们有WebHooks"看看我们的闪亮事件API，当事情发生变化时，它会给你打电话。请停止轮询我们的API，因为它会导致操作团队失败睡眠。水平5： "协调"有一种机制，允许WebHook接收器将接收到的事件与来自查询的时间点查询进行协调API什么5级看起来像吗？因此，有很多方法可以实现这种协调，所有这些都取决于在顶部提供服务的后端类型的。如果您的服务有一个全局单调计数器，它随每次更改和事务隔离而递增，您可以在每个事件负载和查询API响应中包含该计数器值。这使使用者可以决定哪些事件可以忽略，因为它们具有更新的查询API回答。如果您的服务具有全局单调计数器，网络云服务器，但不能为查询提供事务隔离，您可以使用查询响应返回计数器的起始值和结束值，因此，客户机可以将事件分为三个桶，然后他们就可以重新查询与查询并发的事件执行。如果不能提供全局单调计数器，时间戳可用于提供调节。如果你不能提供一个全局单调计数器，也许你可以提供一个单调计数器每个逻辑上下文的计数器。在我们的party API示例中，假设我们的聚会是一个帽子交换聚会，在那里鼓励客人交换帽子。我们可能会公开每个与会者戴什么帽子的API。我们可以为与会者列表设置一个单调计数器，为每个与会者设置一个单调计数器，以跟踪他们当前的变化帽子。那里是一种我认为对某些api非常有用的方法。水花过滤器。基本的想法是这就是复制side选择一个随机种子，根据元素数量和期望精度的估计，给花定尺寸过滤器bloom filter是使用hash（seed+item）填充的，将seed和bloom filter发送给权威侧面。那个权威端运行相同的bloom过滤器群体来构建它的过滤器，并发送任何缺失的事件项目。项目权威方通过发送其bloom过滤器之间的差异来完成复制方的繁荣过滤器复制端再次运行所有的项目删除那些在最后过滤器.注释：为每一轮使用客户端选择的随机种子是为了确保哈希冲突影响每轮不同的元素，因此在一轮中映射到Bloom过滤器相同位的项将被打开后续的不同位子弹。什么我喜欢这种模式的原因是，自力更生和和解实际上没有区别。作为复制器，当我们第一次启动时，我们可以立即开始处理事件。我们的初始bloom过滤器将全部为0，权威方可以以其选择。这个可以通过WebHooks发送对账数据或将其作为查询API返回来实现回应。因为它不能给你完美的和解，它鼓励消费者认识到和解。因为bloomfilter需要最小的状态来计算，并且在处理项的过程中不需要任何顺序，它也不强制任何事务性需求侧面。如果我们让客户机指定要在