速いのは何ですか？REST APIを使用するか、データベースを直接照会しますか？

より速いパフォーマンスとは何ですか？REST APIを作成し、WebアプリでREST APIを使用してデータベースとのすべてのやり取りを行うか、データベースに直接クエリを実行します（つまり、JDBC for Javaなどのデータベースのクエリに使用する一般的なオブジェクトを使用します）？

RESTでの見方：

1. コード内にオブジェクトを作成して、RESTメソッドを呼び出します
2. HTTPメソッドを呼び出す
3. REST API内のコードがデータベースを照会します
4. データベースがデータを返します
5. REST APIコードはデータをJsonにまとめてクライアントに送信します
6. クライアントはJson / XML応答を受け取ります
7. コード内のオブジェクトへの応答をマップする

一方、データベースを直接クエリする場合：

1. データベースをクエリするクエリ文字列でオブジェクトを作成します
2. データベースがデータを返します
3. コード内のオブジェクトへの応答をマップする

これは、REST APIの使用が遅くなることを意味しないのでしょうか？たぶんそれはデータベースのタイプ（SQL vs NoSQL）に依存しますか？

複雑さを追加すると、コードの実行が遅くなります。不要なRESTサービスを導入すると、システムの処理が増えるにつれて実行速度が低下します。

データベースを抽象化することをお勧めします。速度が心配な場合は、リクエストを処理するためにデータベースに触れる必要がないように、データをメモリにキャッシュすることを検討できます。

パフォーマンスを最適化する前に、解決しようとしている問題と使用しているアーキテクチャを調べますが、データベースオプションが直接アクセスとRESTのどちらになるかを考えるのに苦労しています。

速度が心配な場合は、上記の理由により、休憩サービスは遅くなります。ただし、記述するタイプの速度が主な関心事になることはめったになく、もしそうであれば、他の方法で対処できます。時期尚早の最適化はすべての悪の根源です。

相互運用性（モバイル、Web、B2B）が主な関心事であるかどうかを検討してください。RESTはテクノロジーに依存しないため、非常に魅力的です。

データベース用にコーディングするとします。基になるデータストアを変更する場合はどうしますか。基礎となる店舗と密接に結びついている場合、それはどれほど難しいでしょうか？

本当の答えはそれが依存するということですが、うまくいけば私はあなたに考えるべきいくつかのことを与えました！

この質問に答えるのが難しいと思うなら。

正しい一般的な答えは、次のとおりです。

RESTでの見方：

1. コード内にオブジェクトを作成して、RESTメソッドを呼び出します
2. HTTPメソッドを呼び出す
3. REST API内のコードがデータベースを照会します
4. データベースがデータを返します
5. REST APIコードはデータをJsonにまとめてクライアントに送信します
6. クライアントはJson / XML応答を受け取ります
7. コード内のオブジェクトへの応答をマップする

あなたの考えには間違いがあります。

そして、この間違いは、RESTとその原則を完全に理解していないという事実に起因しています。一部のオタクは、Javascript-objectをHTTP経由でネットワーク経由で送信するのがクールだとわかったため、RESTは発明されませんでした。HTTPを使用する主な利点は、キャッシングを使用できることです。結果をキャッシュ可能にすると、DBへのリクエストが少なくなります。そして、マーシャリングは含まれません。回答は直接配信できます。

Insofar @Kleesの答えはまったく正しくありません：

複雑さを追加すると、コードの実行が遅くなります。不要なRESTサービスを導入すると、システムの処理が増えるにつれて実行速度が低下します。

キャッシュ可能な結果を​​処理する場合、アプリケーションに影響はありません。既知の質問に対する既知の回答の配信は、リバースプロキシを介して実行できます。

追加のサービス層を導入すると、常に複雑さとパフォーマンスのオーバーヘッドが発生します。共有キャッシュにより、共有サービス層（REST APIなど）を導入するとパフォーマンスが向上する特定の種類のアーキテクチャがありますが、それはあなたが持っている種類のアーキテクチャではないようです。

同じデータベースに直接接続する複数のWebアプリまたは複数のデスクトップアプリがあるアーキテクチャを検討してください。同じクエリを頻繁に実行する場合、クエリ結果を共有サービスにキャッシュするとパフォーマンスが向上する場合があります。特に、何百ものデスクトップアプリが（Webアプリを介さずに）同じデータベースに直接アクセスし、同じクエリを実行すると言う場合、大きな改善があります。ただし、このアーキテクチャでも、共有サービスを導入する主な理由は、パフォーマンスではなくセキュリティとデータの抽象化でしょう。

しかし、データベースに直接接続する単一のWebアプリがあるように思えます。その場合、追加のサービスレイヤーを導入してもメリットはありません。キャッシュ、データベースの抽象化などは、同じアプリケーションのデータアクセス層で処理できます。

場合によります。

明らかに、コード内のレイヤーが多いほど遅くなります。しかし...直接的なエンドツーエンドのパフォーマンスはスケーラビリティほど重要ではないという点があります。ローカルPCでデータベースにアクセスしているユーザーが1人いる場合、高速で実行できます。同じPCで同じDBにアクセスしている1,000人のユーザーがいる場合、それらすべてがイライラする可能性があります。解決策は、DBを別のボックスに移動し、真ん中にレイヤーを追加することです。1人のユーザーの場合は実行速度は遅くなりますが、1000人がアクセスした場合は高速になります。（それは単純な答えですが、原則としては真実です）。

セキュリティなど、DBを中間層の背後に隠す他の理由があります。

どこで迷子になるかわかりませんが、REST APIを使用している場合は余分なステップを実行していることは明らかです。

長所と短所がありますが、アプリケーションからデータベースに直接アクセスできる場合は、Web APIを使用する代わりに直接呼び出すことをお勧めします。もちろん、Web APIを使用する場合は、アプリケーションを別のプラットフォームに簡単に移植できます。

残り ：

• マルチフロントエンドと1つのバックエンドに対応
• 独自のAPIを作成する必要があります（またはループバックのようなものを使用します）
• オフラインで作業していない

ローカルDB

• 「階層」に開かれていないため、同期するにはバックエンドにアクセスする必要があります
• APIを作成する必要はありません。DBインターフェイスを使用します
• オフラインで作業する

これはかなり大きな違いです。人々はしばしばこれらの点を忘れてしまいました。