[译] 用 API 请求制做赏心悦目的 UX

• 原文地址：Crafting beautiful UX with API requests
• 原文做者：Ryan Baker
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：MeFelixWang
• 校对者：sunhaokk

在构建 Web 应用时，首先要建立一个优雅且响应迅速的体验。

试图控制超出 Web 应用程序范围的体验一般是过后的想法。工程师忘记了处理从 API 请求数据时可能会遇到的全部麻烦事情。在本文中，我将为你提供三种模式（包括代码片断），以使你的应用程序能弹性应对不可预测的情形。

让你的用户和这个愚蠢的人类同样快乐

模式 1：超时

超时是一种简单的模式。简而言之，就是：“若是你的反应比我想要的慢，请取消个人请求”。

何时用

你应该使用超时来设置你但愿请求耗用的时长上限。有什么可能会使你的 API 响应时间比预期的长？这取决于你的 API，但如下是一些现实场景的示例：

你的服务器与数据库进行通讯。数据库宕机了，但服务器的链接超时为 30 秒。服务器将花费完整的 30 秒来肯定它没法与数据库通讯。这意味着你的用户将等待 30 秒！

你使用了 AWS 负载均衡器，其背后的服务器已宕机（不管出于何种缘由）。你将负载均衡器超时保留为默认值 60 秒，而且在失败以前一直尝试链接服务器。

何时不用

若是你的 API 已知响应时间具备可变性，则不该使用超时。一个很好的例子多是返回报告数据的 API。请求一天的数据是快速的（多是亚秒响应时间），但请求八个月的数据大约须要 12 秒。

若是你没法肯定对于请求应该花多长时间的可靠上限，则不要使用超时。

如何使用

假设你的应用程序中有一个方法能够作到这一点：

示例方法可能存在于 React 组件内部

你知道你的 API 在 99％ 的时间里会在 3 秒内响应。假设你使用 Promises 从 API 获取数据，你能够这样作：

为你的 API 调用配置超时

注意：你可能用于进行 API 调用的大多数库都具备超时配置。请使用你工具的内置功能，而不是本身编写

模式 2：最短等待时间

最短等待时间也是一种简单的模式。它与超时相反：它能够保护你的应用免受 API 快速响应的影响。

何时用

若是要向用户显示加载状态，则最短等待时间是一种很是好的模式，但 API 可能会快速响应。结果就是用户会看到加载状态，接着数据“弹出”进入视图，而后其才能专一于想作的事。

这不是一个良好的体验。若是你显示加载状态，你是在告诉用户“稍等，咱们正在处理些事儿，咱们会立刻回来”。这让用户能够喘口气，也许查看一下他们的手机 —— 若是用户看到加载状态，那么用户但愿等待。若是你获取太快，那就太突兀了。你打断了她的休息，让她变得紧张。

何时不用

当你拥有响应速度始终很是快的 API 时，最好避免使用最短等待模式。不要为了添加加载状态而添加，若是不须要，就不要让用户等待。

如何使用

使用上面的示例，你能够编写代码“在这两件事完成以前不作任何事”，以下所示：

强制请求的最短等待时间

模式 3：重试

重试模式是我将要介绍的最复杂的模式。基本的想法是，若是获得错误的响应，咱们想要重试几回请求。这是一个很是简单的想法，但在使用它时须要记住一些注意事项。

何时用

当你向可能发生间歇性故障的 API 发出请求时，你会但愿使用此方法。当知道请求会不时由于没法控制的问题而失败时咱们几乎都但愿重试。

就我而言，当我知道我正在发出使用特定数据库的请求时，我会常用它。访问该数据库时，有时它会失败。是的，这很糟糕。是的，这是咱们应该解决的问题。做为应用程序开发人员，当被告知“暂时处理它”时，咱们可能没有能力修复底层基础架构问题。这就是你想要重试的时候。

何时不用

若是咱们拥有可靠的且始终如一的响应式 API，则无需重试。若是响应失败而且重试后依然不能成功响应，那咱们也就不须要重试了。

大多数 API 都是一致的。这就是为何你须要当心这个模式：

如何使用

咱们但愿确保在发出请求时，不会对服务器形成冲击。想象一下由于负载太重形成服务器宕机的情形吧。重试将把一个已死的服务器再埋到六英尺深的地下。出于这个缘由，咱们在进行后续请求时须要所谓的退避策略。咱们不但愿在服务器宕机的状况下仍然当即一个接一个地发出 5 个请求。咱们应该错开它们以减小 API 服务器上的负载。

大多数状况下，咱们使用指数退避来肯定在发送下一个请求以前咱们应该等待多长时间。咱们一般只想重试 3 次，因此这里有一个使用不一样函数的等待时间示例：

当即发送第一个请求。它失败了。接下来，咱们须要肯定在发送第一次重试以前使用退避策略等待多长时间。让咱们看一下这些曲线，其中 X 等于咱们已经发送的重试次数。

使用咱们的二次（y = x²）函数和线性（y = x）函数，在第一个等待时间内咱们获得 0，即应该当即发送下一个请求。

因此能够在运行时消除这两个函数了。

使用指数（y = 2^x）函数和常数（y = 1）函数，咱们获得 1 秒的等待时间。

常数函数使咱们没法灵活处理已经发送的重试次数，从而改变咱们应该等待的时间。

这就只剩下指数函数了。让咱们编写一个函数，来告诉咱们根据已经发送的重试次数肯定等待多少秒：

简单的 y = 2^x 函数

在编写重试函数以前，咱们想要一种方法来肯定请求是否错误。假设状态码大于或等于 500 时，请求是错误的。这个就是咱们能够为此编写的函数了：

若是响应错误，咱们的函数会抛出自定义错误

请记住，你可能有不一样的标准来肯定请求是否失败。最后，咱们可使用指数退避策略编写重试函数：

咱们使用指数退避策略重试

你会注意到我建立了一个我没有导出的函数（_retryWithBackoff）。使用咱们的重试函数时，调用代码不能在迭代中显式传递。

总结

有不少很好的防护模式能够提供良好的用户体验。这三个你今天就可使用！若是你有兴趣了解更多，我建议阅读 Release It！一本关于如何在构建可扩展软件时解决这些确切问题的书。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。