6

現在、新しい Web サイト用にバージョン管理された API を設計中です。ルートに名前を付ける方法は理解していますが、モデル内でバージョン管理されたメソッドを実装する最善の方法に行き詰まっています。

以下のコード サンプルは Rails フレームワークを使用していますが、問題の原則はほとんどの 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

明らかに、ここでは Product で使用可能な属性を公開しているだけです。このソリューションは、API のバージョンが 1 つしかない場合にうまく機能します。V2 をリリースしたいのですが、V2 で製品名の表示方法を再実装する必要がある場合はどうなりますか (V1 との下位互換性を維持しながら - 少なくとも短期的には)。

私が見る限り、いくつかのオプションがあります...

  1. V1 のサポートをすぐに中止し、フォールアウトに対処する (考えられる最悪の解決策)
  2. 新しい属性を含めるために to_[format] メソッドをオーバーライドし始めます (as_[format] でこれを行うと確信していますが、それは重要ではありません)... name_2- これは同様にばかげているようです
  3. 必要なメソッドのみを公開する役割を担うある種のプロキシ クラスを実装します。
  4. ビューに、バージョン管理されたコントローラーが呼び出すある種のハッシュの作成を処理to[format]させます...

Three と Four は、私が実際に何らかの意味があると考えることができる唯一のものです... Three は次のようになります。

# 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

他の人は過去に何をしましたか？

4

2 に答える 2

6

V1 と V2 と V を提供する 1 つのアプリではなく、バージョンごとに 1 つのアプリをデプロイします。1 つのアプリが api.domain.com/v1 に応答し、別のアプリが api.domain.com/v2 に応答するなどです。

これが、サービス指向アプリケーションを最適に編成する方法であり、各サービスを分離し、独立した展開にする必要があります。

1 つのアプリからすべてのバージョンを提供することは、サービス指向設計の目的に反します。1 つのサービスを変更するたびに、すべてをテストしてデプロイする必要があるからです。

于 2011-07-23T00:46:51.483 に答える
-1

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

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

于 2012-05-13T20:35:48.047 に答える