定義済みのThrift APIをリタイアするベストプラクティス？

Question

下記のシナリオで何が起こるのか不思議ですか？

1. 定義されたAPIは、最新のリフトサービス定義で削除されます。
2. サーバ側の実装が最新の定義にアップグレードされます（つまり、削除されたAPIについての実装はこれ以上ありません）。
3. クライアントの中には、古いサービス定義にとどまり、削除されたAPIへのトラフィックが残っているものがあります。

もっと一般的な質問としては、既存のAPIをリタイアする（つまり、.thriftファイルで定義された）のが一番良いと思いますか？

Answer 1

これは、ソフトウェアのバージョン管理の利点の1つです。これは、スリフト専用の機能ではありません。 APIは時間の経過とともに変化する可能性があり、特定の非常に最小限の一連のルールが適用される限り、アプリケーションが動作する明確な方法があります。

スリフトに関して、これらの規則には、特定の構造体メンバまたは引数の特定のフィールドIDの型を決して変更しないでください。サービス名とメソッド名も同じです。数値フィールド/引数IDとサービス/メソッド名は、ワイヤ上のデータで使用される識別子です。したがって

、

• フィールド/引数の変更の種類は、数値IDも廃止されている
• フィールドとメソッドがに（IDLから除去されない、コメントすべきで変更する必要がある場合言及する価値）後で再利用されることを防ぐ

最後のポイントは、requiredの使用についてです：この属性は、公開APIの構造体メンバ、because of the way of how the required semantics workから削除されないことがあります。

これ以外の場合は、古いクライアントが新しいサービスを呼び出すときに互換性の問題になります。逆の場合も同様です。