2011-07-23 12 views
6

私は現在、新しいウェブサイトのバージョン管理されたAPIを設計中です。私はルートの名前空間をどのようにするかを理解していますが、モデル内でバージョン管理されたメソッドを実装する最良の方法についています。APIウェブアプリケーション内のバージョン管理

以下のコードサンプルでは、​​レールフレームワークを使用していますが、問題の原則はほとんどのWebフレームワーク間で一貫している必要があります。

MyApp::Application.routes.draw do 
    namespace :api do 
    namespace :v1 do 
     resources :products, :only => [:index, :show] 
    end 
    end 
end 

とコントローラ:

ルートは、現在のようなものを見て

class Api::V1::ProductsController < V1Controller 
    respond_to :json, :xml 

    def index 
    respond_with @products = Product.scoped 
    end 

    def show 
    respond_with @product = Product.find(params[:id]) 
    end 
end 

だから、明らかに私たちはここの製品で使用可能な属性を暴露しているあなたの場合、このソリューションは、」素晴らしい作品APIの1つのバージョンのみを使用します。 V2をリリースしたいときに何が起こりますか?V2は、製品の名前の表示方法を再実装する必要があります(少なくとも短期間でV1との下位互換性を維持します)。

すぐ

V1のための私の知る限り、それはあなたがオプションのカップルを持って見るように...

  1. ドロップのサポートや放射性降下物(最悪の可能な解決策)
  2. に対処するあなたはTO_をオーバーライド開始[フォーマット]メソッド(これは、as_ [フォーマット]でこれを行うことを確信していますが、それはポイントの横にあります)を新しい属性を含めるには... - これは全く同じように見えます
  3. 公開する責任を負っている、我々が後にしている方法
  4. は、ビューがバージョンのコントローラというハッシュのいくつかの種類を作成任せと

3と4は、私が実際に意味のいずれかの種類を作ると考えることができる唯一のものです...上to[format]を呼び出す...スリーになりますlike:

# model 
class Api::V1::Product < Struct.new(:product) 
    def to_json 
    attributes.to_json 
    end 

    def to_xml 
    attributes.to_xml 
    end 

private 
    def attributes 
    {:name => product.name} # add all the attributes you want to expose 
    end 
end 

# Controller 
class Api::V1::ProductsController < V1Controller 
    respond_to :json, :xml 

    def show 
    respond_with @product = Api::V1::Product.new(Product.find(params[:id])) 
    end 
end 

過去に他の人が行ったことはありますか?

答えて

6

V1とV2とVを提供する1つのアプリの代わりに、各バージョンに1つのアプリをデプロイします。 1つのアプリケーションがapi.domain.com/v1に応答し、別のアプリケーションがapi.domain.com/v2などに応答するようになります。

これは、サービス指向のアプリケーションがどのように構成されているか、各サービスは独立した展開である必要があります。

サービスごとに変更を加えるたびに、すべてのサービスをテストして展開する必要があるため、1つのアプリケーションからすべてのバージョンをサービスすることはサービス指向設計の目的を凌駕します。

+0

これは本当に良い解決策です - 私が考えていなかったもの... – Coop

-1

個別のバージョンを作成する予定がある場合は、APIをオーバーエンジニアリングしている可能性があります。 URLとプロパティを削除しない限り、古いクライアントは引き続きAPIを使用できます。 APIがバグや奇妙なことを回避しているときにクライアントを分離する方法として、v1、v2などを使用してください。

元のAPIがサポートできるものを超えて基礎となるアーキテクチャを変更している場合は、古いクライアントをサポートする予定の場合は古いプラットフォーム用のプロキシを作成する必要があります。新しいシステムでは、@Nerianが示唆するように全く新しいエンドポイントサーバーを作成します。

関連する問題