2011-10-01 26 views
5

私はDjangoを使ってプライベートな休息のようなAPIを実装していますが、バックエンドでさまざまなバージョンのAPIを処理する方法がわかりません。複数のバージョンでapiのバックエンドを実装する方法

意味は、私は2つのバージョンのAPIを持っていれば、私のコードはどのように見えるのですか?別のバージョンを扱う別のアプリを用意する必要がありますか?異なる機能が異なるバージョンを扱うべきか?あるいは、もしあるバージョンが別のバージョンと異なる場合にはif文を使うべきですか?

ヘッダーにバージョンを記載する予定です。

ありがとうございました

答えて

3

REST APIをバージョンする必要はありません。 RESTでは、バージョン管理は実行時に「must-ignore payload extension rules」と呼ばれるものか、コンテンツネゴシエーションを介して行われます。

'must-ignore payload extension rules'は、メッセージのデザインに組み込まれた側面を指します。 'Must-ignore'は、指定された形式のメッセージを処理するソフトウェアが未知の構文構造を無視しなければならないことを意味します。これは私たちがHTMLから知っていることであり、パーサが窒息することなくあらゆる種類のファンシータグをHTMLページに挿入することが可能になっています。

'Must-ignore'は、古いバージョンのみを理解しているクライアントを考慮せずに、既に送信したものにサービスを追加することでサービスの機能を発展させます。

コンテンツネゴシエーションは、サーバーが実行時に特定のクライアントに送信する実際の表現をネゴシエートするHTTP組み込みのメカニズムを指します。一般的なシナリオは次のとおりです。クライアントは、要求にAcceptヘッダーを送信して、可能なことを宣言し、サーバーは、これらの機能に基づいて返信する表現を選択します。しかし、このテーマのバリエーションもあります(詳細はhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec12.htmlを参照)。

コンテンツネゴシエーションは互換性のない変更を可能にします。つまり、互換性のない古いバージョンと新しいバージョンを送信できるようにサービスを進化させることができ、私のサービスが適切なものを送信するAcceptヘッダーに基づいています。

ボトムライン:どちらのアプローチでも、APIはそのままです。 APIレベルでバージョン管理を行う必要はありません。特に、URIにバージョン識別子を含めることは頻繁には推奨されていません(ただし、SOAPではなくRESTを実行しています)。

+0

どのように後方互換性のないデータベース/モデルの変更、古い/デプロイされたクライアントの移行期間中の作業の継続を可能にしますか? –

関連する問題