APIを実行すると、content-typeヘッダーを修正すると、顧客にとって問題が発生しますか？
かなりの数の人がそれを使ってAPIを実行しています。一部のレガシーの不器用さのため、エンドポイントの1つが間違ったコンテンツタイプヘッダー、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クライアントライブラリは、プログラマがそのヘッダーを明確に読み取って何かを実行しない限り、コンテンツタイプヘッダーを無視します。 content-type：application/jsonが自動的にjsonパーサーを関与させるライブラリを想像できますが、実際にそれが発生するケースは知りません。
ほとんどの人はcontent-typeが間違っていることに気づいていないようですが、時々新しいサポートリクエストがこの問題について不平を言っているので、それを修正したいと思います。
彼らは誤ったヘッダーにどのように気づきましたか？不正なヘッダーが実際に問題を引き起こしている場合、それらは単にそれを無視しているのではなく、修正されていると問題が発生する可能性があるため、一見の価値があります。
すべてのクライアントからの承認を得ずに判断するのは難しすぎます。 APIをv.Nextにアップグレードするには、次の2つの方法のいずれかをお勧めします。
- 既存のAPIを拡張します。 v.Nextを使用することを示すクエリ文字列またはその他の変数をAPIに追加します。その変数を使用するすべてのリクエストで、更新されたコンテンツタイプを使用します。
- 現在のAPIと並行して、APIのステージングまたはプリプロダクションインスタンスを実行します。本番環境とほぼ同じです。同じバックエンドを使用していても。これにはv.Nextの提案された変更があります。
どちらのシナリオでも、行う変更と目標カットオーバーの日付/時刻をクライアントに伝えます。サービスの中断がないことを確認するために、目標日よりもかなり前にテストするように彼らに勧めます。
V.Nextに加えられた変更を詳細に説明する専用ページがあることを確認します。これは、クライアントに送信される通信に含める必要があります。既存のクライアントと修正について話し合った場合は、このページに修正を含めてください。
最後に、顧客との過剰なコミュニケーションとそれらへのスパム送信の間の境界線を踏みます。これらの通知は、緊急性の高い優先度が高くなると見落とされがちです。
FWIW、物事が現在機能している場合、私はそれについてあまり心配しません。たとえば、これが重大なセキュリティの脆弱性を引き起こすことがわかった場合、それがこの変更をプッシュする大きな理由になります。そうでなければ、私はこの変更を含めるためにもっと切迫した何かを待ちます。
これが壊れるライブラリ（まあ、単一のコマンド）の例です。
powershell コマンドレット Invoke-RestMethod はJSONとは異なる動作をします。リクエストの結果がJSON、XML、またはATOM/RSSである場合（そして、ヘッダーに基づいていると思います）、それは解析または逆シリアル化され、ネイティブオブジェクトを返します。それ以外の場合は、生データを返します。
したがって、既存のコードは文字列を処理するように記述されます（おそらくそれを ConvertFrom-Json ）、そして突然の開始が失敗するでしょう。