9
SpringでREST APIのバージョン管理を行う方法は？
Spring 3.2.xを使用してREST APIバージョンを管理する方法を検索してきましたが、メンテナンスが簡単なものは見つかりませんでした。最初に私が抱えている問題を説明し、次に解決策を説明します...しかし、ここで車輪を再発明するのかどうか疑問に思います。 Acceptヘッダーに基づいてバージョンを管理したいと思います。たとえば、リクエストにAcceptヘッダーが含まれている場合、application/vnd.company.app-1.1+jsonSpring MVCがこれをこのバージョンを処理するメソッドに転送するようにします。また、APIのすべてのメソッドが同じリリースで変更されるわけではないので、各コントローラーに移動して、バージョン間で変更されていないハンドラーを変更する必要はありません。また、Springは既に呼び出すメソッドを検出しているため、コントローラー自体で使用するバージョンを判別するロジックは必要ありません（サービスロケーターを使用）。 ハンドラーがバージョン1.0で導入され、v1.7で変更されたバージョン1.0から1.8のAPIを取り上げたので、これを次のように処理します。コードがコントローラー内にあり、ヘッダーからバージョンを抽出できるコードがいくつかあると想像してください。（Springでは以下は無効です） @RequestMapping(...) @VersionRange(1.0,1.6) @ResponseBody public Object method1() { // so something return object; } @RequestMapping(...) //same Request mapping annotation @VersionRange(1.7) @ResponseBody public Object method2() { // so something return object; } 2つのメソッドに同じRequestMappingアノテーションがあり、Springがロードに失敗するため、これはSpring では不可能です。アイデアは、VersionRangeアノテーションがオープンまたはクローズドバージョン範囲を定義できるというものです。最初の方法はバージョン1.0から1.6まで有効ですが、2番目の方法はバージョン1.7以降（最新バージョン1.8を含む）で有効です。誰かがバージョン99.99に合格することを決めた場合、このアプローチはうまくいかないことを知っていますが、それは私が共存しても問題ありません。 さて、春はどのように機能するかを真剣にやり直さなければ上記は不可能なので、ハンドラーをリクエストに一致させる方法をいじくり回すこと、特に自分自身を書くことを考えていました ProducesRequestConditionでそこにバージョン範囲を持たせることを考えていました。例えば コード： @RequestMapping(..., produces = "application/vnd.company.app-[1.0-1.6]+json) @ResponseBody public Object method1() { …