APIを実行し、コンテンツタイプヘッダーを修正すると、顧客にとって問題が発生しますか？

かなりの数の人が使用しているAPIを実行しています。原因私の部分にいくつかのレガシー不器用に、エンドポイントの1つは戻っている間違ったContent-Typeヘッダを、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が正しくないことに依存するコードを記述した場合、戦艦を完全に沈める可能性があります。

ライブラリーがエラーをスローすることは期待していませんが、場合によっては、厳密なライブラリーの動作がオーバーライドされて、誤ったMIMEタイプを処理することを期待しています。

APIのリクエストフィールドにバージョン/リビジョン値がある場合、それを上げて、新しいバージョンでは正しいタイプを返しますが、古いバージョンでは間違ったタイプを返し続けます。このようなリクエストフィールドがない場合は、今すぐ追加してください。

このような変更が発生した場合、多くの異なるHTTPクライアントライブラリが致命的なエラーをスローすると予想しますか

いいえ。私が使い慣れているすべてのHTTPクライアントライブラリは、プログラマーがヘッダーを特別に読み取って何かを行わない限り、コンテンツタイプヘッダーを無視します。content-type：application / jsonがjsonパーサーを自動的に関与させるライブラリを想像できますが、実際に発生するケースは知りません。

ほとんどの人は、コンテンツタイプが間違っていることに気付かないようですが、この問題について不平を言う新しいサポートリクエストが時々出てくるので、修正したいと思います。

彼らはどのように間違ったヘッダーに気付きましたか？間違ったヘッダーが実際に問題を引き起こしている場合、それを無視しているだけではなく、修正されている場合は問題がある可能性があるため、それを見る価値があるかもしれません。

すべてのクライアントからサインオフせずに伝えるのは難しすぎる。APIをv.Nextにアップグレードするには、次の2つのアプローチのいずれかを取ることをお勧めします。

1. 既存のAPIを拡張します。v.Nextを使用することを示すクエリ文字列またはその他の変数をAPIに追加します。その変数を使用するすべてのリクエストに対して、更新されたコンテンツタイプを使用します。
2. 現在のAPIと並行して、APIのステージングインスタンスまたはプリプロダクションインスタンスを実行します。本番とほぼ同じである必要があります。同じバックエンドを使用しても。これにはv.Nextの提案された変更がありますが。

いずれのシナリオでも、クライアントに行う変更と目標カットオーバーの日付/時刻を伝えます。サービスの中断がないことを確認するために、目標日よりも十分前にテストするように奨励します。

v.Nextに加えられた変更の詳細を記載した専用ページがあることを確認してください。これは、クライアントに送信される通信に含める必要があります。既存のクライアントと修正について議論した場合は、このページに修正を含めてください。

最後に、顧客との過剰なコミュニケーションと顧客へのスパムとの境界線を踏みます。これらの通知は、より即時/緊急の優先度が出てくると簡単に見落とされる可能性があります。

FWIW、物事が現在機能している場合、私はそれについてあまり心配しません。たとえば、これが重大なセキュリティ脆弱性を引き起こすことがわかった場合、それがこの変更を推進する大きな理由になります。それ以外の場合は、この変更を含めるために何かもっと緊急なことを待ちます。

これが壊れるライブラリ（単一コマンド）の例を次に示します。

PowerShellのコマンドレットは、Invoke-RestMethodJSONとは異なる動作します。要求の結果がJSON、XML、またはATOM / RSSの場合（ヘッダーに基づいていると思います）、それを解析/逆シリアル化し、ネイティブオブジェクトを返します。それ以外の場合は、生データを返します。

したがって、既存のコードは文字列を処理するように記述され（おそらくそれをに渡すことでConvertFrom-Json）、突然開始が失敗します。

私は2つの結果に気づきました：

1. 一部のクライアントライブラリは、応答を適切に処理しません。たとえば、応答はjsonまたは配列の代わりに文字列を返します。
2. 圧縮は常に適用されるとは限りません。