公共 API 的错误次数远超你想象

作者 | Matt Hawk

译者 | 苏本如，责编 | 郭芮

头图 | CSDN 下载自东方IC

出品 | CSDN（ID：CSDNnews）

以下为译文：

想知道API的使用在当今的软件开发过程中有多普遍？那就去问问工程师们在他们的项目中集成了多少API吧。大多数开发团队可能不知道确切的答案。然而我们知道，从分析工具到地图应用和云托管，现代应用程序都使用了大量的内部和外部API。开发人员们都在使用这些工具来快速组装应用程序，以减少构建这些应用程序所需要花费的时间和精力。然而，这其中有一个被遗忘的成本，通常在项目的早期并没有被考虑到。

当你将另一个API添加到你的软件中时，它的影响在最初集成之后的很长一段时间都能感受到。开发人员需要维护和这些外部API的连接，包括在它出现问题时定位和解决问题。通常情况下，这些问题不会浮出水面，直到接到用户的错误报告，这对于大多数公司来说，已经为时已晚。然而通过应用程序构建过程只能发现那些最常出现的中断性功能错误。

在本文中，我们将讨论API出现错误时的用户体验以及它们的常见程度。同时，我们还将讨论一下我们需要做什么来减少这些API问题。

客户对API集成中断的体验

现代应用程序依赖大量的API来为用户提供高质量的功能。无论一个产品是Web应用、桌面应用还是移动应用，无论是在前端还是在后端，开发人员都会严重依赖第三方API提供的功能。当这些API出现错误时，客户无法区分哪些错误属于开发人员，哪些错误属于第三方。他们看到的只是一个“坏”掉的应用程序。一个坏的API会导致糟糕的客户体验，进而导致收入的直接损失。

比如，假设你正在构建一个新的自行车共享应用程序。你需要编写大量原始代码，但也可以在现有工具的基础上进行构建。事实上，大多数开发人员都不会尝试重新创建那些可以通过现有API提供的最常用的基础设施。

因此，你的应用程序可能需要集成如下服务：

• 云托管服务

• 显示自行车位置的地图服务

• 位置换算的地理编码API

• 支付服务

• 通信服务

如果你想共享自行车，显然你需要知道它们在哪里，并将这些位置信息数据共享给用户。因此，你需要在谷歌地图上标出自行车的位置。根据你的盈利模式，你甚至可能需要跟踪用户的取车地点和目的地之间的距离，以便按距离（英里）收费。

在这种情况下，你的应用程序也需要一个支付系统。你可能需要集成Stripe来支持信用卡付款，或者通过集成Plaid（一种金融服务API，最近被Mastercard收购）来支持银行卡付款。

即使是最简单的应用程序，你也需要一些附加功能。你可能需要发送短信或电子邮件的功能。或者集成一个安全的聊天功能，就像你在Lyft或Craigslist上看到的那样。同时，你可以集成SendGrid或MailChimp这样的服务来实现邮件提醒的自动化，以便让你的客户群保持活跃。

突然间，你发现自己已经坐在一个庞大复杂的系统上，它不仅使错误更难跟踪和修正，而且意味着你的应用程序的功能必须严重依赖无数的第三方服务来最小化和跟踪他们自己的错误。然而，从用户的角度来看，应用程序的任何一个组成部分的故障，都意味着整个应用程序的故障。

开发人员会频繁地监控自己开发的系统的性能并及时解决发生的问题。这包括编写单元测试、偿还技术债务和经常重新评估功能。另外，他们可能会引入质量保证团队来发现用户的体验问题。

然而，许多开发团队并没有采取相应的措施来对他们使用的外部API进行同样的监控和分析。缺乏这些措施，他们很容易忽视外部API对用户体验的影响。对于和外部API的集成，你应该采取与代码质量控制相同的严格措施。这样，当应用程序的响应时间超过上限或者功能出现错误时，你会立即收到提醒和通知。

公共API发生错误的次数比你想象到的要多

随着越来越多的应用程序依赖于公共API，一个众所周知的事实是，公共API并不可靠。每个API都有很多发生错误的情形，而大多数应用程序都包含有多个API。你需要对API可能发生的错误有所预料，在理想情况下，你需要能够尽量减少这些错误。你绝对不能等待客户自己报告问题。如果你的客户已经去了别的地方，这些错误将不会自行修复。而客户遇到这些问题时，他们很大可能不会去调查这些问题是由哪里引起的。

SmartBear在其发布的2019年API统计报告中指出：

“那些将API监控视为首要任务的组织在解决性能问题方面的表现远远优于那些没有这样做的组织”。

该报告将这一现象归结于极高的客户期望。他们的调查发现，57%的API用户希望问题能在一天内解决，40%的用户希望问题能在12小时内解决。

API返回请求失败的原因有很多：

响应时间：在人们期望值很高的今天，一个慢的应用程序可能和一个坏的应用程序一样糟糕。响应时间就像煤矿中的金丝雀，预示着更大的问题即将来临。

错误代码不匹配：正确的状态代码有助于及时调整API错误，但你不能总是指望API提供程序发送它。在某些情况下，你会收到一个200状态码 - 这意味着没有发生错误 - 但是接收到的API响应里仍然包含有错误的详细信息。在这种情况下，一个调查数据的人可能会发现有问题，但软件并不知道错误已经发生并向任何人报告。

授权凭证(Authorization Credential)：API对发出请求的人执行权限认证，以确定是否是正确的人在获取信息。这有助于保持系统和数据的安全，但也增加了另一层风险，这种风险可能导致有效的请求也可以触发错误。权限认证可能发生超时错误或者授权凭证被吊销。但是，这时候用户只能看到错误消息，没有任何解释。

速率限制（Rate Limit）：许多API通过对请求实现速率限制来控制流量（限流）。这些限制可能是基于一天的流量，或者是基于每秒的流量。建立处理速率限制的逻辑（比如429个错误）是非常耗时的。另外，如果API出现问题，应用程序因为限流不能够自动重试，它就不能提供更好的用户体验并减少数据丢失。

虽然许多开发人员都采用了某种形式的API监控，但他们并不总是关注外部API。通常情况下，API监控要求团队主动而为而不是被动为之。这意味着你需要在错误发生之前确切地知道要查找哪些错误。并且你需要知道那些你没有预料到的错误。团队必须具备这些洞察力，才能满足用户的期望。

消除API问题需要做什么？

现代应用程序需要大量地连接到外部API才能正常地工作。就像任何一台复杂的机器一样，当一个齿轮错位时，系统就会崩溃。要识别和修复API错误，需要在你每次调用API时使用一些复杂的技术工具。仅仅依靠API监控远远不够，你需要使用重试逻辑和异常检测。

积极主动地进行API维护意味着对API网络有高度的了解。每次用户发送请求时，你都需要知道它花费了多长时间以及返回了哪些数据。洞悉这些有助于预测未来何时可能发生错误。同时，如果API请求返回了错误，你必须能够查看请求的详细信息并做出快速响应。

这样的话，API错误的范围就可以仅限于少数用户。不幸的是，开发人员很少能够使用这些复杂的工具。这些工具内部构建困难，并且需要耗费大量时间和资源。

Hoss公司正在关注这个问题。我们用于跟踪和管理公司使用的API的平台可以帮助开发人员减少这些麻烦，并避免API性能差带来的破坏性影响。该服务提供了一个完整的、易于理解的API分析仪表盘，因此开发人员可以制作更好的API驱动的产品和提供无缝的用户体验。API的激增带来了巨大的好处，但同时也带来了巨大的成本，而懂得采取行动降低这些成本的开发人员必将在即将到来API的繁荣中占据有利地位。

原文：
https://hackernoon.com/what-is-the-true-cost-of-using-public-apis-lz7x3wn7

本文为 CSDN 翻译，转载请注明来源出处。