JAX-RS と JAX-WS は、API の作成に最適です。ただし、下位互換性の問題にはまったく対処していません。
API に新しい機能が導入されたときに古いクライアントが壊れないようにするには、基本的に、以前とまったく同じ入力および出力形式を受け入れて提供する必要があります。XML パーサーや JSON パーサーの多くは、何にもマップされていないフィールドや間違った型のフィールドを見つけた場合に適しているようです。
Jackson や Gson などの一部の JSON ライブラリは、ランタイム設定に基づいて、特定のオブジェクトに対して異なる入出力表現を指定できる機能を提供します。これは、多くの場合にバージョン管理を処理する適切な方法のようです。これにより、追加および削除されたフィールドに注釈を付けることで下位互換性を提供できるため、クライアントが使用している API のバージョンに従ってのみ表示されます。
私がこれまでに見つけた JAXB も他の XML データバインディング ライブラリも、この概念を適切にサポートしていません。それを JAXB-RI または EclipseLink Moxy に追加することは潜在的に可能に思えますが、困難です。
バージョン管理のもう 1 つの方法は、変更されたすべてのクラスをバージョン管理することです。多くの場合、API が公開されるたびに新しいパッケージを作成し、変更されたすべての DTO、サービス、およびリソース クラスを新しいパッケージにコピーして、タイプ情報は、バインディングおよびディスパッチ システム用にバージョン管理されます。このアプローチは、私にはもっと面倒に思えます。
私の質問は、下位互換性のために Java API プロバイダーをどのように設計したのですか? 何が機能し、何が機能しなかったか?
この件に関するケーススタディまたはブログ投稿へのリンクは大歓迎です。私はいくつかのグーグルを行いましたが、これについての議論はあまり見つかりませんでした。