运行API，如果我更正了内容类型标头，会为客户带来麻烦吗？

我们正在运行许多人使用的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的浏览器，但也有一些。

大多数人似乎没有注意到content-type是错误的，但是不时出现一个新的支持请求，抱怨这个问题，因此我们想修复它。

它会给我们现有的客户带来多大的麻烦？

如果他们编写的代码依赖于此Content-Type不正确，则可能会完全击沉他们的战舰。

我不希望这些库引发错误，但是我希望在某些情况下，严格的库的行为已被改写以处理错误的MIME类型。

如果您的API在某处的请求字段中具有版本/修订值，请提高它，并在新版本中返回正确的类型，但在旧版本中继续返回错误的类型。如果您没有这样的请求字段，那么现在是添加一个请求字段的好时机。

看到这样的变化时，您会期望许多不同的HTTP客户端库引发致命错误吗？

不会。我熟悉的每个HTTP客户端库都将忽略内容类型标头，除非程序员专门读取了该标头并对其进行了处理。我可以想象一个库，其中的内容类型：application / json会自动导致json解析器参与其中，但是我不知道实际发生的任何情况。

大多数人似乎没有注意到content-type是错误的，但是不时出现一个新的支持请求，抱怨这个问题，因此我们想修复它。

他们如何注意到错误的标题？可能值得一看，因为如果错误的标头实际上导致了他们的问题，那么他们显然不仅会忽略它，而且如果它已修复，他们可能会遇到问题。

没有得到所有客户的批准，很难说出来。我建议采用以下两种方法之一将您的API升级到v.Next。

1. 扩展现有的API。向您的API添加一个查询字符串或其他一些变量，以表示使用v.Next。对于使用该变量的所有请求，请使用更新的内容类型。
2. 与您当前的API并行运行您的API的Staging或Pre-Production实例。它应该与生产几乎相同。即使使用相同的后端。尽管此版本将具有v.Next的建议更改。

在任何一种情况下，请与您的客户交流您要进行的更改以及目标转换日期/时间。鼓励他们在目标日期之前进行良好的测试，以确保不会中断服务。

确保您有专门的页面，详细说明了对v.Next所做的更改。这应该包括在发送给您的客户的通信中。如果您已与现有客户端讨论了任何修复程序，请在此页面上进行修复。

最后，要在与客户过度沟通与向客户发送垃圾邮件之间加分。随着更多紧急/紧急优先事项的出现，这些通知很容易被忽略。

FWIW，如果目前一切正常，我不会对此太担心。例如，如果您发现这会导致严重的安全漏洞，那么这就是推行此更改的重要原因。否则，我将等待更多的压力来包含此更改。

这是一个可能会中断的库示例（很好，单个命令）：

在PowerShell的 cmdlet的Invoke-RestMethod使用JSON的作用是不同的。如果请求的结果是JSON，XML或ATOM / RSS（并且我认为它基于标头），则它将解析/反序列化它并返回本机对象，否则返回原始数据。

因此，现有的代码将被编写为处理字符串（也许通过将其传递给ConvertFrom-Json），并且突然开始失败。

我注意到了两个后果：

1. 某些客户端库将无法正确处理响应。例如，响应返回一个字符串，而不是json或数组。
2. 压缩并不总是适用。