19

ロジスティックの質問があります。アプリと同期しなくなったAPIを管理するための最良の方法を見つけようとしています。それを説明する最良の方法は、例を使用することです。

MyAppバージョン1.0が、first_name、last_name、およびemailを必要とする「submit_feedbacK」APIに投稿するとします。

次に、MyAppバージョン2.0をAppStoreに送信します。このバージョンは、first_name、last_name、gender、およびemailをAPIに投稿するように設計されています。これらはすべて、APIの必須フィールドです。

私が抱えている問題：-新しいアプリがライブになる前にAPIを更新すると、バージョン1.0が壊れます-バージョン2.0がライブになり、リモートで1.0が機能しなくなるまで待つと、正しくタイミングを合わせる必要があります。

「正しい答え」は、2つの異なるAPIを維持することだと思います。しかし、両方のAPIが同じライブデータベースに投稿する場合、それは物事を少し厄介にします。

これをモデル化する方法について誰かが提案を持っていますか？

4

3 に答える 3

8

この質問は、 iOS 消費 API 設計といくつかの側面を共有している可能性があります。

正しい答えは、間違いなく 2 つの API を提供することです (少なくとも、ユーザーが慣れるまでの短期間)。2 つのバージョンを同時に維持する必要はありません。新しいバージョンがリリースされたら、そのバージョンを維持し、レガシー ユーザーに古いバージョンを提供するだけです。実際に変更する必要があるのは、セキュリティ パッチや主要な問題などだけです。大きな変更 (データベース全体の再構築を決定するなど) により、古いバージョンが機能しなくなる可能性がありますが、新しい API バージョンへの更新は、以前のバージョンが引き続き機能するように設計する必要があります。

私があなたにリンクした他の質問は、アプリの異なるバージョンが正しいバージョンの API にアクセスする方法についての答えを提供します。

もう 1 つの注意点は、(使用しているフレームワークによっては) API をエンジンまたはサブアプリとして設計し、それらを別のエンドポイントにマウントする方が簡単な場合があることです。これは Rails ではエンジンを使用して簡単に実行でき、Node では Express で app.use() とサブアプリケーションを使用して簡単に実行できることを知っています。

于 2013-03-04T19:48:10.920 に答える
0

参考までに、CodeIgniterを使用しています。https://github.com/philsturgeon/codeigniter-restserverで提供されているRESTコントローラーを使用しています。最終的には、バージョンごとに異なるエンドポイントを使用することにしました。基本的に、リリースごとに新しいリポジトリをチェックアウトして、一意のディレクトリに配置します。（つまり、http ：//www.mysite.com/1.0/api/method、http：//www.mysite.com/1.1/api/methodなど）1つのコードベースで複数のバージョンのAPIを維持しようとしています怖すぎるように聞こえた。少なくとも私がバージョンをリリースしたとき、私はそれが石に閉じ込められていることを知っていて、それを壊すことを心配する必要はありません。（注：同じドメインから複数のCodeIgniterインスタンスを実行するには、特別な.htaccess調整を使用する必要がありました。必要に応じて共有できます）

于 2013-03-11T22:47:00.613 に答える
0

アプリとの通信には webservice/http エンドポイントを使用します。アプリのすべてのバージョンで同じ URL を維持したい場合は、サーバーへのすべての要求/投稿にバージョン番号を含めて、処理方法を認識できるようにします。これにより、新しいバージョンがサーバー上の新しい API に対してテストできるため、開発とテストも容易になります。

したがって、webservice/server で呼び出すことができるすべての関数で、バージョン番号を持つ単一の変数を追加します。同じ関数の 256 バージョンに到達したら (もしあれば)、最初からやり直して「v1.0 のサポートを終了」できると思うので、BYTE で十分なはずです。

サーバーがデータを含むリクエスト/ポストを受信したら、サーバー API で単純なスイッチ/ケース構造をコーディングするだけで、両方のバージョンでサポートが機能します。

彼らが似ている場合、例えば。パラメータなどを交換すると、これらすべてのサーバー側を処理でき、ソリューションのサーバー部分で BAL/DAL (n 層構造) を維持できます。

ところで。私の答えは、iOS やスマートデバイスだけではなく、まだ開発と保守が行われている間、すべてをオンラインにする必要がある「進行中の」生産セットアップのためのクライアント/サーバー アプローチです。

それが理にかなっていることを願っています。そうでない場合は、コメントしてください。さらに説明しようと思います。

于 2013-03-11T11:41:02.670 に答える