老旧的API，你应该如何处理？

<div id="js_content">
点击关注下方卡片关注我????????
回复“程序员”查阅程序员精选文章
作者 | Tim Perry
译者 | 张卫滨
策划 | 万佳
来自前端之巅公众号
废弃 API 端点是一项非常具有挑战性的工作，我们需要考虑所有依赖该 API 的客户端，避免出现级联的故障。针对该问题，有两个新的 HTTP 头信息草案，本文详细阐述了该如何使用这两个新的头信息安全地关闭 API。
万物都会有终结，HTTP API 也不例外。不论你的 API 今天看上去多么伟大，迟早有一天你会想发布一个全新的版本，新版本能更好地解决相同问题，在各方面可能都会有所改善，但是它因为有了新参数，与旧版本也无法兼容，或者你只是想彻底关闭旧的 API。总而言之，你现在的 API 不会永远存在。
但是，这并非轻而易举就能完成的，因为你的 API 有客户端。如果你关闭端点、参数或整个 API 而没有做出恰当的警告的话，那他们肯定会非常不爽。
那么，该怎样安全地关闭 API，让你的用户尽可能地感到轻松愉快呢？
在这方面，我们有正确的做事方式，包括两个新的头信息草案，它们正在被新的 IETF “Building Blocks for HTTP APIs”工作组进行标准化，旨在形成一个精确的过程。我们了解一下。
1. 制定计划
初始第一步：检查相关的 API 是否真的有客户端。
希望你能有某些 API 的度量指标，至少在某些地方存有日志。如果没有的话，那把它们添加上，如果你有这些东西的话，并且你能确定没有人再使用这个 API 了，那么恭喜你，你赢了。现在，你就可以把它关掉，删掉代码，不要再管这篇文章了，好好睡一觉。
下一个问题，如果比较遗憾，你无法去睡觉的话，那就要问问自己，除了关闭这个 API，还有没有其他方案。你关闭的所有东西都有可能破坏别人的代码，并且会消耗他们的时间来修复这些问题。如果 API 能继续运行的话，对客户端的生态系统和整个 web 的健康都是有好处的。
在很多场景下，旧的 API 可以在内部进行转换，透明地转化成对新 API 的调用，这样可以避免维护两个完全独立的版本。这是 Stripe 的 API 版本管理方式的一个基本组成部分，他们在所有发生变化的 API 中都包含了转换，以确保对不兼容的旧版本 API 的请求能继续像以前那样运行，根据需要自动转换请求和响应从而可以使用较新的代码。
https://stripe.com/blog/api-versioning#versioning-under-the-hood
这样的转换并不总是可行的，而且如果永远这样做的话会带来明显的额外复杂性，但是如果你可以做到这一点的话，就能为用户提供非常有价值的稳定性，并且可以节省大量废弃旧版本或维护旧版本相关的工作。
但是，如果这个服务 / 端点 / 参数已经用到了生产环境，而且继续支持它是不现实的做法，那么它必须要被淘汰。
要实现这一点，我们就要有一个计划。我们首先要问自己三个关键的问题：
你希望用户该怎么做？常见的答案包括：升级到相关功能的一个更新的、依然能得到支持的版本；使用一些可替代的端点 / 参数 / 服务；使用不同的服务，它们与你无关，不需要你关心。
用户应该何时迁离这个 API？你所提出的替代方案现在就可以用了吗？
截止时间是什么时候？也就是，这个 API 何时会完全停止使用？（如果不能完全确定的话，你可以稍微延迟回答这个问题）。
计划准备就绪之后，我们就该把它告诉人们了。
2. 沟通
首先，要把这一决定告诉人们。
发邮件到邮件列表，在 Twitter 或微博上发帖，如果有 API 规范的话，对其进行更新（比如，OpenAPI 在 operations 和 parameters 上有一个<code>deprecated</code>字段），并在相关的在线文档上大声强调这一点。
你应该包含上文提到的所有信息：他们应该做些什么作为替代方案，你建议他们什么时候开始迁移以及他们必须要进行迁移的最后期限（如果已经确

老旧的API，你应该如何处理？

浏览过的版块