3

Web アプリケーション用の iOS アプリを開発します。(Web アプリはコード イグナイターを使用します)

iOS アプリが使用する API サービスを作成します。

api版を作ろうと思っているので、web apiが変わるとiOSアプリが知るようになります。

懸念：

  • Web アプリケーション API が変更された場合、iOS アプリを更新する必要があります (レガシー API を利用可能にしておく場合を除きます。これは適切なオプションですか)。
  • Web アプリ API が更新されていないときに iOS アプリが更新されると、これも問題の原因となります

iOS アプリは、必要な API のバージョンを指定する必要がありますか?

  • iOS アプリの API が Web API 未満の場合: 表示メッセージ: iOS アプリを更新してください
  • iOS アプリ API が Web API より大きい場合: 表示メッセージ: Web アプリを更新してください

これはベストプラクティスですか？

バージョンごとに api クラスを作成し、以前のバージョンを拡張してメソッドが変更されたときにメソッドをオーバーライドする必要がありますか?

例

ApiV1 extends CI_Controller
{
   function list_customers(){//Code}
   function saveSale() {//Code}
}

ApiV2 extends ApiV1
{ 
   function saveSale()
   {
      //New way of saving sale
   }
}

また、v1 API が機能しなくなるデータベース構造に変更を加えるとどうなりますか? （例：データベースのテーブル名を変更？）

4

3 に答える 3

9

一般に、サービスAPIとクライアントの間にかなり緩い結合を作成する必要があります。原則として、クライアントの複数のバージョンが常に野生に浮かんでいるため、ユーザーにアップグレードを強制することはできるだけまれにしたいと考えています。

APIバージョンの完全な改訂は、実際にはWebサービスではややまれであり、通常、データモデル、セキュリティモデルなどの大幅な変更にのみ対応します。複数のバージョンを共存させるには、サービスに追加の作業が必要になる場合がありますが、価値がある場合があります。既存のクライアントが機能し続けることができるようにします。

そのためには、現在のクライアントUIのニーズに関係なく、抽象エンティティとして使用している「モデル」について、事前に設計を慎重に検討してください。（特定のケースについてより具体的な考え方が必要な場合は、ニーズのモデル化について別の質問を投稿することをお勧めします。）ただし、要件は必然的に変化するため、すべてのニーズを前もって解決することについてあまり心配しないでください。

これを行ったら、サービスAPIにバージョン管理の概念を組み込んで、将来に備えてください。考慮すべきいくつかの事柄：

  1. URLスキームの一部としての明示的なバージョン、または認証ハンドシェイクなどで最初に指定されたバージョン。これは、クライアントがアクセスするものをきれいに名前空間化する方法です。（前者はサービスで明示的なURLルーティングを行い、後者は認証トークンを解読した後にルーティングするためにより多くの体操を必要とします。）
  2. 「このAPI呼び出しは廃止されました」という意味の既知のエラー応答。これは、以前のクライアントが認識して、クライアントに更新が必要であることをユーザーに通知できます。

サービスでは、メソッドオーバーライドを備えたコントローラーを使用して、設計を明示的にすることができますが、少し高いレベルです。saveSaleメソッドがバージョン間で大きく異なる動作をする可能性はほとんどありません。ベースラインを実行するメソッドがV1にある可能性が高く、saveSaleたとえばV2に余分なデータを保存する可能性があります。その場合、その余分なデータが存在する場合、コードは条件付き分岐を持っている可能性があります。これはすべて、サービスAPIが実際にはそれほど頻繁に非互換的に変更されないという別の言い方です。list_customers時間の経過とともにより多くの情報を返す可能性があります。これは、APIに新しいバージョンが必要であることや、古いクライアントが不要な追加情報を無視してはならないことを必ずしも意味するものではありません。

Re：データベーステーブル名に関する最後の質問。これらは内部で変更される可能性がありますが、クライアントに表示されるものに明示的にマップする必要はありません。APIは安定したインターフェースであり、進化し続けるサービスの実装の詳細を理想的に隠す必要があります。

全体として、APIが実行する必要のある全体像が大幅に変更され、既存のクライアントのニーズに平和的に対応できないと判断した場合は、APIを改訂することを選択します。特定のクライアントバージョンのサポートをサービスで維持すると、インストールベースの価値よりも頭痛の種になると判断した場合は、特定のクライアントバージョンを廃止して廃止することを選択します（非常にビジネス/ケース固有の問題）。

幸運を。

于 2013-03-10T19:46:43.923 に答える
0

iOS アプリで必要な API のバージョンを指定することが適切かどうかはわかりませんが、安全な方法だと思います。ただし、API を頻繁に更新する場合、アプリを頻繁に更新する必要が生じるのはすぐに面倒です。

従来のメソッド名を保持し、別の名前のメソッドを追加して、Web API を変更したときにユーザーがアプリの新しいバージョンに更新する必要がないようにします。

以前のバージョンの API を拡張するために、バージョンごとに API クラスを作成するわけではありません。

データベース構造を変更するには、ほとんどのインスタンス/状況で実行可能/実用的/便利ではない、テーブル名または定義またはデータのレガシーバージョンを保持したくない場合を除き、API の変更/更新が必要になると思います。この場合、ユーザーに新しいアプリと API に更新してもらいます。

API 設計の原則と実践のプレゼンテーションを指すこの回答を見てください。

于 2013-03-11T19:18:50.007 に答える
0

どのようなベスト プラクティスがあるかはわかりませんが、iOS アプリが探している API のバージョンを追跡し、具体的にはそのバージョンを要求することを強くお勧めします。たとえば、「/api/v1/....」の URL です。この方法で API を更新するときは、単純に別のバージョン ('/api/v2/...') にアップし、iOS アプリが消費するために v1 をそのままにしておくことができます。明らかに、iOS ユーザーにメッセージを表示する必要があります。新しいバージョンが存在する場合にアップグレードします (おそらく応答のメタ フィールド)。

このアプローチにより、アプリをアップグレードできなかった人々を切り離すことなく、API の開発を継続できるはずです。

アップデート

あともう一つだけ; 以前のバージョンを操作不能にする変更 (テーブル名、スキーマなどの変更など) を行う場合は、iOS アプリが理解できるステータス コードが必要です。「この API バージョンは廃止されました。更新する必要があります。

API が非推奨になった場合 (つまり、新しいバージョンが存在する場合) にも、同様のヘッダー (または何か) をお勧めします。明らかに、要求された情報/アクションを提供し続けますが、バージョンがサポートされなくなり、アップグレードする必要があるという警告 (またはアプリ内でアップグレードする何かをトリガーすることさえ) が役立つ場合があります。

于 2013-01-25T19:05:49.263 に答える