サーバー容量と統合するときの問題に対する便利でシンプルなソリューション-完全に適合する2つの製品を作成し、相互に一貫性のあるデータを提供し、それ自体が障害なく動作するタスクがある場合の対処方法。
Egor Taflanidi、Redmadrobotの詳細。
自給自足の製品を作成しない場合（そして実際にはモバイルプラットフォーム上にそのようなものはほとんどありません）、いわゆる「ビジネス」アプリケーションを作成します。通常、その背後には最新データを提供し、時間のかかるタスクを解決するサーバーがあります。
サーバー/クライアントバンドルはモバイル開発環境に根ざしているため、インターネットに接続していない最新の「スマートフォン」は単純にレンガになります。 一部のライブラリとフレームワーク（ RhoMobile / RhoConnectなど ）は、このサーバー/クライアント統合を中心に構築されており、「 内部 」に深く残されています。
このようなアーキテクチャーの実装には、多くのアプローチがあります（理想的には互いに適合し、互いに一貫したデータを提供し、それら自体がスムーズに機能する2つの製品）。
- 開発は1人に任せることができます（または、同じ部屋に座っている密接に協力するチームも同じことです）。 彼は必要なすべてのノードを結合し、統合のすべての問題を最も効果的に解決します。
- サーバーソフトウェアの開発パートナーにサーバーの実装を提供できます。
- 顧客は独自のサーバー開発者チームを持っている場合があります-これは多くの場合、銀行との協力の場合に当てはまります。
残念ながら、どちらのオプションを選択しても、サーバー/クライアント相互作用プロトコルの明確に定義された仕様でさえ、正しい統合を提供できないことがよくあります。 また、クライアントとサーバーのプロトコルが一致しないという単純で明らかな問題が発生します 。
クライアント開発の観点から、これはモバイルアプリケーションが誤ったデータを受信するという事実につながります。 または、まったく受け取りません。
アーキテクチャ設計が十分に「防弾」ではなく、開発にほとんど時間が割り当てられていない場合、アプリケーションは「落ち」、ごみを表示し、一般的に見苦しくなります。
したがって、フィードバックの正確性は保証されません。アプリケーションからシリアル化されたデータがサーバー上で適切に認識されると誰が言ったでしょうか？
になる方法
最初に頭に浮かぶのは、モバイルアプリケーション内のすべてのパーサーとシリアライザーを、サーバーから既に提供されているものに合わせるという卑劣な決定です。
次のような種類のJSONを取得します。
{
データ：{
「Field1」：「value1」、
「Filed2」：「value2」
}
}
仕様で指定されているものの代わりに：
{
データ：{
「エンティティ」：{
「Field1」：「value1」、
「Filed2」：「value2」
}
}
}
貴重な情報-「 field1 」と「 field2 」はそのままです。 それでは、ちょっとしたトリックを許可しないのはなぜですか-すでに提供されているものから情報を読み取るには？
「 一貫性 」というキーワードについてはすでに言及しました。 文字通り、英語から「 一貫して実行する 」=「 一貫して実行する 」という意味で、「 特定の行動規範に従う 」という意味で。
たとえば、最初に現象が「 現象 」と呼ばれた場合、ドキュメントでは「 現象 」と呼ばれるべきであり、ソースコードでは「 Phenomenon 」クラスである必要があり、受信JSONではキー「 現象 」が必要です。
すべてのプロジェクト参加者が同じ用語集を使用すると、誤解のリスクが大幅に減少します。
遅かれ早かれ、開発者の1人がドキュメントの不一致を検出し、修正することができます。 そして、システムの反対側では、すべてが崩壊します。
さらに、すでにサーバー用に作成されたドキュメントに基づいて、他のモバイルプラットフォーム、場合によってはデスクトッププラットフォーム用に他のクライアントを作成できます。同じ問題が発生します。実装はドキュメントに対応していません。
これにより、松葉杖でシステムが成長し始め、内部から腐敗します。
解決策
http://apiary.io
小規模なサービスは非常にシンプルで機能がかなり制限されていますが、魅力的です。 APIのモック実装を提供します。
モバイルアプリケーションを設定できる一意のURLを取得します。 キットには、実装されたすべてのプロトタイプWebサービスに関するきちんとしたドキュメントに加えて、これらのWebサービスから送信される典型的な応答が含まれています。
たとえば、いくつかのエンティティエンティティのセットをレンダリングするサーバーが必要です。 ユーザーのリスト、レストランのリスト、ATMのリストは重要ではありません。
各エンティティには独自のIDがあり、これによりサーバーはこのエンティティに関する詳細情報を提供できるはずです。
さらに、APIは、たとえばサービス情報（ タイムスタンプフィールド）-エンティティが特定のIDで更新された時間を個別に提供する必要があります。
したがって、次のものがあると仮定します。
住所
サービス1 ：
- エンティティのセットをGETリクエストに返します
- POSTリクエストで、新しいエンティティの追加の確認を返します
サービス2 ：
- GETリクエストは、エンティティに関する詳細情報を返します。
- UPDATE要求で、エンティティの更新の確認を返します
サービス3 ：
- GETリクエストでは、エンティティの最後の更新の日付を返します。
等
このような「サーバー」の例はこちらです。
模擬サービスの説明は非常に単純で、本質的に宣言的です。
新しいモックAPIを作成すると、すぐにサンプルが提供されます。
フォーマット：1A
ホスト：http://www.application.com
＃アプリケーション
Notes APIは、*短いテキストの保存*テーブル上の物理的な紙の存在に似たサービスです。
＃グループノート
** Notes APIのNotes関連リソース**
## Notesコレクション[/ notes]
###すべてのメモのリスト[GET]
+応答200（アプリケーション/ json）
[{
「id」：1、「title」：「公園でジョギング」
}、{
「id」：2、「title」：「郵便局からのピックアップポスター」
}]
###メモの作成[POST]
+リクエスト（アプリケーション/ json）
{「タイトル」：「朝食にチーズとパンを購入します。」 }
+応答201（アプリケーション/ json）
{「id」：3、「タイトル」：「朝食にチーズとパンを購入します。」 }
このコードは、GETおよびPOST要求に応答するサービスの操作を記述します。
そして、apiary.ioサービス自体がプロキシとして機能できます。 1つのスイッチで、ブレッドボードサーバーに着信するすべてのトラフィックを、クライアントのソースコードを変更せずに「戦闘」バックエンドにリダイレクトできます。
すべてが素晴らしく、すべてが美しく、プロセスをブロックせずにチームが作業できるようにし、便利なスクリプト言語を提供します...
問題は、残念ながら、彼には特別な論理がないことです。
IDに応じてエンティティのリターンをシミュレートできますが、いずれにしても、状況を分析することができない有限状態マシンになります。目的は少し異なります。
http://www.soapui.org
少し深く掘り下げる必要がある場合は、問題ではありません。 古い、実績のあるSoap UIが常にあります。
SoapUIは、SOAPおよびRESTサービスを自動モードでテストすることを目的に設計されたマルチタスクコンバインです。 とりわけ、彼自身が適切なサーバーとして機能し、ブレッドボードデータを提供できます。
アクションの手順：
プロジェクトを作成し、そこから不要なものをすべて切り取ります
新しい模擬RESTサービスを作成する
アクションを追加
エンティティのリストを返しましょう
模擬データを追加する
認証キーの存在によってのみ、サービスがこのリストを返すようにします。
「無許可」ユーザーの回答を追加します
ディスパッチモードを「SCRIPT」状態に切り替え、リクエストパラメータをチェックする指定された例の1つをコピーします
開始します（サービス設定でポートを確認した後、デフォルトで-8080）
確認する
すべて、ブレッドボードサーバーの準備ができました。
結論
当然、上記のサービスは唯一のものではなく、同様の機能を提供するmockable.ioなどの類似物が多数あります。
残念ながら、これらのソリューションのほとんどは、通常、可能なネットワーク要求に対する本格的な応答を実装する柔軟性を欠いています。
モックAPIを作成するための本当に機能的で便利なサービス-それほどではありません。
一方、このようなソリューションのシンプルさにより、比較的迅速な展開が保証され、プロジェクトのある段階でこれが決定的な要因になる可能性があります。
そのため、apiary.ioはプロトタイプまたは概念実証ソリューションの作成に関与している可能性があり、プロジェクトの進化に伴い、ロジック、スクリプトを使用したより高度なサービスへのその後の移行について既に考えることができます...
そこに見える-バトルサーバーは既に準備ができています。
もちろん、別の記事はBAASサーバーですが、これは少し異なる話です。
統合の問題をどのように解決しますか？