API コードにバージョニング システムを実装します。システムは sinatra 上に構築され、デフォルトの API バージョンがあり、クライアントは HTTP Accept ヘッダーを追加する特定のバージョンを選択できます。
ここで、API バージョン情報をコントローラー内に厳密に保持するか、API バージョンを何らかの方法でモデル内に渡すことを許可するかを理解したいと思います。コントローラーに保持する場合、API バージョンをモデルに伝達することの短所は何ですか?
API コードにバージョニング システムを実装します。システムは sinatra 上に構築され、デフォルトの API バージョンがあり、クライアントは HTTP Accept ヘッダーを追加する特定のバージョンを選択できます。
ここで、API バージョン情報をコントローラー内に厳密に保持するか、API バージョンを何らかの方法でモデル内に渡すことを許可するかを理解したいと思います。コントローラーに保持する場合、API バージョンをモデルに伝達することの短所は何ですか?
RESTful API設計では、バージョン管理はメディアタイプの選択を通じて行われます。これは、あなたがやろうとしていることだと私は信じています。2番目の段落を正しく理解した場合、バージョン情報も配信された応答内(つまり、ドキュメントモデルの一部)に含める必要があるかどうかを尋ねていますか?
このような決定は恣意的ですが、多くの形式は、メタデータ(バージョン情報など)が失われる可能性のある不可逆システムを通過する場合に備えて、バージョン情報を内部に保持します。このため、モデルに配置することをお勧めします。
API のバージョン管理は、コントローラーが内部でバージョン管理を処理し、モデルと通信することを意味しません。モデルは内部でバージョン管理も処理します。代わりに、リクエスト内の API のバージョンに基づいて、実行時にスワップインおよびスワップアウトするコントローラーとモデルの異なるバージョンが必要であることを意味します。
さて、Sinatra の言及から、Ruby を使用していると思います。Sinatra や Ruby についてはほとんど知りませんが、ASP.NET MVC 4 に関する同様の質問に回答し、 Sebastiaan Dammann によって作成されたバージョン管理フレームワークについて説明しました。
Ruby 用の同様のフレームワークが既に存在するかどうかを確認してください。