深思熟虑的设计还必须考虑到 API 的性能，如果 API 不能响应越来越多的请求，不能满足不断变化的业务需求，不能按预期运行，良好的设计就毫无意义。

与任何性能一样，API 性能在很大程度上取决于 API 如何响应它收到的不同类型的请求。

比如：我们有一个客户端应用程序，显示客户的当前订单。应用程序从 API 获取订单详细信息。但现在，客户表示，他们想查看所有订单。因此，我们构建了一个“我的订单”页面，用于显示客户的所有订单。这意味着，我们的 API 将返回比以前更多的数据，比以前承受更大的负载。

如何确保我们的 API 能够返回所有数据而不会出现延迟、服务器端错误和过多请求等问题?这里有一些性能提升的最佳实践：

传输数据量大的时候，必然会导致 API 性能下降，而最直接的办法就是降低 API 传输的负载(payload)，我们可以使用 GZip 压缩来缩小有效载荷的大小，可以在 Web API 上使用 Deflate compression。或者，我们可以将 Accept-Encoding 标题更新为 gzip。

缓存是提高 API 性能的最简单方法之一。如果我们的请求相同的 API，那么该响应的缓存版本有助于避免额外的服务调用或数据库查询。

在使用缓存时，您需要选择合适的缓存淘汰算法，在发生新数据更新时，缓存也要及时更新。

即使是设计最强大的 API，缓慢的网络也会降低性能。不可靠的网络可能会导致停机，解决这个也相对简单，多花钱投资于适当的网络基础设施，这样我们才能保持理想的性能水平。

此外，如果您有大量后台进程，请在单独的线程上运行这些进程，以避免阻止请求。还可以使用镜像和 CDN在全球不同地区更快地服务请求。

API 可能会受到 DDoS 攻击，该攻击可能是恶意和故意的，也可能是工程师调用API在某些本地应用程序的循环中执行时故意的。可以通过测量交易并监控每个 IP 地址或每个SSO/JWT令牌的每秒调用次数，对恶意请求进行屏蔽来避免这种情况。

这种速率限制方法有助于减少对 API 的过度请求，并主动监控和识别可能的恶意活动。

工程师们普遍认为，PUT 和 PATCH 操作会产生相同的结果。他们在更新资源方面相似，但他们各自执行更新的方式不同：PUT 操作通过向整个资源发送更新来更新资源。PATCH 操作仅对需要更新的资源应用部分更新。因此 PATCH 调用产生较小的负载，并大规模提高性能。

不过，即使 PATCH 调用可以限制请求大小，也应该注意它不是幂等的。PATCH 可以通过一系列多个调用产生不同的结果。因此，应该仔细和故意地考虑您的应用程序是否使用 PATCH 请求，并确保在需要时它们可以幂等地实现。如果没有，请使用 PUT 请求。

如果你应该从这篇文章中学到一件事，那就是这个!日志记录、监控和警报是 API 最重要的组成部分，没有之一。

拥有日志、监控和警报有助于工程师在发生问题之前对其进行诊断和补救。许多API(基于Express/Node、Java、Go)都有预定义的接口来评估以下内容：

/health 
 
/metrics

如果没有启用日志记录，并且存在潜在问题，将无法跟踪来源，或特定请求中出现问题的地点。如果没有启用监控，将无法从分析角度知道一些问题或错误的发生频率。这将不利于做出合理的解决方案。而且，如果没有启用警报，将不知道是否有问题，直到客户(或更糟糕的是客户)报告它。这就比较严重了!

数据量大时，分页是个很好的策略，不过分页也不是银弹，数据量大时依然会非常慢。一个有效的策略是最多显示前 100 页，几乎没有人会翻到 100 页之后。

前后端分离已是常态，对于后端开发来说，最重要的就是设计一个强大的 API，针对 APi 的性能进行适当优化和增强，它可以非常强大，为企业和客户提供出色的体验。作为负责任的工程师，我们有责任决定如何以高性能的方式构建我们的 API，这可以帮助我们实现和超越我们的目标。

原文来自：

本文地址：//lrxjmw.cn/improve-api-performance.html编辑：J+1，审核员：逄增宝

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：