既存の Rails アプリ用に ruby と Sinatra を使用して API を開発しています。アプリケーションを分離した (マウント ロジックなし) ため、これらは個別にデプロイされます。本番環境では、両方のアプリケーションのプロキシ サーバーとして nginx を使用しています。これは、ドメイン マッチングを使用して適切なアプリケーションにディスパッチします。
API のバージョン管理も行っています。現在、get、post、filters などを呼び出すメソッドを上書きすることにより、Sinatra アプリケーション自体でそれを行っています。そのため、リクエスト uri に一致するために適用する文字列または正規表現ルールに関係なく、それらは追加する前のバージョン管理:
# matches /v0.1/resource/:id
get "/resource/:id" ....
これには、少なくとも URL の最初の部分 (first / included) を常に一致させる必要があるという欠点があります。そうしないと、バージョン番号が正しく追加されません。それだけでなく、アプリケーションごとに 1 つのバージョンの API のみを照合することも意味します。
私はまだ最初のバージョンに取り組んでいるので、API のバージョン バンピングが続くにつれて、先に進むための最善の戦略を見つける時間があります。考えられる戦略は 2 つあります。
それをすべて la Rails にして (Railscast で残りの API のバージョン管理を推奨しているように)、アプリ内で常に一致するバージョンを作成します。
get "/0.1/resource/:id" do ..... get "/0.2/resource/:id" do .....これには、常に 2 つ (またはそれ以上) のバージョンのロジックがあり、URL マッチング ロジックがより複雑になるという欠点があります (たとえば、/\d+/resource/\d+ のような 1 つのルールですべてを一致させたい場合は、バージョン番号が受け入れられるかどうかを確認する必要があります)、スパゲッティの発生を全体的に増やします。
これには、同じデプロイ ロジックを維持できるという利点があります (最後のバージョンを現在の nginx ルートに置き換えて、1 つの API のみにルーティングするなど)。
nginx をバージョン別にディスパッチします。CVS を使用して、コードをバージョン管理できます。オンラインでサポートするバージョンの数を定義し、それらを展開してから、ドメイン + バージョン ベースになる nginx ルーティングを再配置するだけで済みます。
これには、ロジックに必要なルールのみを一致させるため、アプリケーション ロジックをクリーンアップできるという利点があります。最後の例を使用します。
get "/resource/:id" do ....nginx は適切なアプリケーションへのルーティングを処理します。
ただし、これにはいくつかの技術的な欠点があります。これを機能させるには、展開戦略を変更する必要があります。つまり、サポートする API のバージョン数を選択し、CVS からそれらを取得してから、nginx 構成を編集し、削除する必要があります。最後の API ルール、新しいもの (api.myapp.com/v1、api.myapp.com/v2 へのルーティング...) を挿入し、nginx を再初期化します。もう1つの欠点は、たとえばバグ修正のために複数のAPIコードベースをサポートする必要があることです...これは上記と同じですが、異なるバージョンタグ付きコードベースをサポートするだけで済みます.
他のユーザーがこの問題をどのように解決したか、またそれがその後のメンテナンスにどのように影響したかを知りたいです。