RESTful APIを使用したDerby

Question

私はダービーに非常に興味があり、昨晩のドキュメンテーションを読んで過ごしました。現在の私の考えは、対応するリッチ・クライアント・アプリケーション、またはAPIへのアクセス権を持つ他の誰かによって使用されるRESTful APIを構築することに非常に重点を置いています。

ダービーはスピードに焦点を当てているだけでなく、ウェブが（ページに一致するURLで）想定されているように非常に機能するため、私に印象的です。しかし、最近、モバイルアプリケーションを製品に適合させる動きに伴い、モバイルとブラウザの両方の領域を開発するために必要なAPIが必要になると思われます。

私の質問は二重です。

1. APIとのインターフェイスに使用することができます。基本的にAPIアダプタを作成し、mongoadapterと交換することができます。私はアダプターを見ていないが、アダプターの作成はそれほど難しくないと暗示している。あるいは、acceptsヘッダがjsonを要求する場合、API呼び出しに対するjson応答を生成することもできます。そうすれば、Webアプリケーションを提供するとともにAPIとしての役割を果たすことができます。

2. 他のアプリ（モバイルなど）には、アプリケーション全体として使用する必要はありません。つまり、ブラウザとモバイルアプリの間の共通の要素は、APIではなくデータベースになります。共通の要素としてAPIを使用しないことの欠点は、機能がアプリ全体で一貫していない可能性があることです（機能の量と同じではなく、一方がバグではない可能性があります）。

次のプロジェクトではderbyを使用したいと思っていますが、それが仕事のツールであるかどうかを明確にする必要があります。

Answer 1

1. は、私はあなたが書くことができると思います（ちなみにこのプロジェクトは大きなWebアプリケーションであってもよいが、モバイル統合を持っている必要があります。APIを持つことも、素晴らしいアイデアことが、私はその有用性はまだよく分からないかもしれません） （実際にデータが格納されている）api-appと通信するためのアダプタですが、このアダプタは事前定義されたメソッドを持ち、APIを反映しません。ビジネスロジックがおそらく（derby appとapi app）複製され、このソリューションから多くの利益を得ることはできません。

2. derbyをapi-appとして使用することをおすすめします。バージョン0.6から（それはまもなく）サーバーサイドなしでクライアント側のderbyアプリケーションを使用できます。つまり、例えばphonegapで使用できます。また、derbyには、share.jsに基づく競合解決機能が組み込まれたクライアント同期機能があります。あなたはウェブのためにそれを使用して "ボックスの"アプリケーションをphonegapすることができますが、ネイティブのモバイルアプリケーションの場合はshare.jsクライアントにそれを使用するように書くべきです。また、share.jsに内蔵されている残りのAPIもあります。また、あなたは簡単にエクスプレスルートに基づいてAPIを実装できます。したがって、derbyはapi、web、phonegap apps、モバイルアプリ向けに最適です。