我们正在运行一个API，有相当多的人使用它。 由于我的一些传统的笨拙，其中一个端点是返回错误的内容types的头 ， 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，但也有一些。
大多数人似乎没有注意到内容types是错误的，但是不时地出现一个新的支持请求，抱怨这个问题，所以我们想修复它。
我们现有的客户有多糟糕？
如果他们编写的代码依赖于这个内容types是不正确的，它可以完全沉没他们的战列舰。
我不希望库发生错误，但我认为在某些情况下，严格的库会重写它们的行为来处理不正确的MIMEtypes。
如果您的API在某个请求字段中具有版本/修订版本值，请将其提升，并在新版本中返回正确的types，但在旧版本中继续返回不正确的types。 如果您没有这样的请求字段，现在是添加一个的好时机。
你会期望许多不同的HTTP客户端库在看到这样的变化时抛出致命错误吗？
不。每个我熟悉的HTTP客户端库都会忽略内容types的头文件，除非程序员专门读取头文件并对其进行处理。 我可以想象一个库的内容types：应用程序/ json自动导致jsonparsing器涉及，但我不知道任何情况下实际发生。
大多数人似乎没有注意到内容types是错误的，但是不时地出现一个新的支持请求，抱怨这个问题，所以我们想修复它。
他们是如何注意到不正确的标题？ 这可能值得一看，因为如果不正确的标题实际上是造成他们的问题，他们显然不只是忽略它，如果它是固定的，它们可能会有问题。
很难说，没有得到所有客户的签名。 我build议采取以下两种方法之一将您的API升级到v.Next。
无论在哪种情况下，都要向客户传达您想要作出的更改以及目标转换date/时间。 鼓励他们在目标date之前进行testing，以确保没有服务中断。
确保你有一个专门的页面，详细说明v.Next所做的更改。 这应该包含在发送给你的客户的通信中。 如果您已经讨论了现有客户端的任何修补程序，请将其包含在此页面上。
最后，在与客户进行过度沟通和垃圾邮件之间划清界线。 随着更多的紧急/紧急优先事项出现，这些通知很容易被忽略。
FWIW，如果目前正在工作，我不会太担心。 例如，如果您发现这会导致严重的安全漏洞，那么推出此更改将是一个很好的理由。 否则，我会等待一些更加紧迫的事情来包含这个变化。
下面是一个库的例子（以及单个命令）：
PowerShell cmdlet Invoke-RestMethod与JSON的行为不同。 如果请求的结果是JSON，XML或ATOM / RSS（我认为它是基于头的），它会parsing/反序列化它并返回本地对象，否则返回原始数据。
所以现有的代码将被写入处理一个string（也许通过传递给ConvertFrom-Json ），并会突然开始失败。
我注意到了两个后果：