我们正在运行一个 API，有不少人使用它。由于我的一些遗留问题，其中一个端点返回了错误的内容类型标头，js而它应该是json。我的问题是，如果我们通过交换来返回正确的值来解决这个问题，这会给我们现有的客户带来多大的麻烦？或者换句话说，当看到这样的变化时，你会期望许多不同的 HTTP 客户端库抛出致命错误吗？
我们正在试图决定这是否是一个我们可以继续进行而不必过多担心的改变，或者我们应该仔细地向所有用户发送电子邮件并宣布一个多年的弃用期......或介于两者之间的某种方式。
这可能有点取决于所使用的 HTTP 客户端类型，所以我查看了用户代理。答案：有很多不同的代理！以下是一些最常用的代理：
“okhttp/3.2.0”、“python-requests/2.10.0”、“Ruby”、“python-requests/2.7.0”、“Mozilla/5.0”、“Java/1.8.0_91”、“python-requests/2.4.3”、“okhttp/3.3.0”、“Lucee”、“Dalvik/2.1.0”、“Google-HTTP-Java-Client/1.21.0”、“PHP_appname”、“NativeHost”、“Java/1.7.0_67”、“Apache-HttpClient/UNAVAILABLE”、“Dalvik/1.6.0”、“Web-sniffer/1.1.0”、“unirest-objc/1.1”
各种不同的移动端和服务器端语言库。大多数不是运行 javascript 的浏览器，但有些也是。
大多数人似乎没有注意到内容类型是错误的，但时不时会出现一个新的支持请求来抱怨这个问题，所以我们想修复它。
答案1
它会给我们现有的客户带来多大的困扰？
如果他们编写了依赖于此的代码，它可能会彻底击沉他们的战舰内容类型是不正确的。
我不希望库抛出错误，但我预计在某些情况下严格的库会覆盖其行为来处理不正确的 MIME 类型。
如果您的 API 在请求字段的某个位置有版本/修订值，请将其提升，并在新版本中返回正确的类型，但在旧版本中继续返回不正确的类型。如果您没有这样的请求字段，现在是添加一个的好时机。
答案2
当看到这样的变化时，您是否认为许多不同的 HTTP 客户端库会抛出致命错误？
不会。我熟悉的每个 HTTP 客户端库都会忽略 content-type 标头，除非程序员专门读取该标头并对其进行处理。我可以想象一个库，其中 content-type: application/json 自动导致 json 解析器参与其中，但我不知道有任何这种情况实际发生的情况。
大多数人似乎没有注意到内容类型是错误的，但时不时会出现一个新的支持请求来抱怨这个问题，所以我们想修复它。
他们是如何注意到错误的标头的？这可能值得一看，因为如果错误的标头确实给他们带来了问题，他们显然不会只是忽略它，而且如果修复了它，他们可能会遇到问题。
答案3
如果没有得到所有客户的认可，很难说清楚。我建议采用以下两种方法之一将您的 API 升级到 v.Next。
- 扩展现有 API。向您的 API 添加查询字符串或其他变量，以表示使用 v.Next。对于使用该变量的所有请求，请使用更新的内容类型。
- 与当前 API 并行运行 API 的暂存或预生产实例。它应该与生产几乎相同。甚至使用相同的后端。不过，这个实例将包含针对 v.Next 的建议更改。
无论哪种情况，都要向客户传达您想要进行的更改以及目标切换日期/时间。鼓励他们在目标日期之前进行测试，以确保不会中断服务。
确保您有一个专门的页面详细说明对 v.Next 所做的更改。这应该包含在发送给客户的通信中。如果您与现有客户讨论过任何修复，请将其包含在此页面中。
最后，要把握好与客户过度沟通和向他们发送垃圾邮件之间的界限。当出现更紧迫的优先事项时，这些通知很容易被忽视。
不管怎样，如果一切进展顺利，我不会太担心。例如，如果您发现这会导致严重的安全漏洞，那么这将是推出这一更改的一个很好的理由。否则，我会等待更紧迫的事情来包含这一更改。
答案4
我注意到了两个后果：
- 某些客户端库无法正确处理响应。例如，响应返回的是字符串，而不是 JSON 或数组。
- 并不总是应用压缩。