何が速いですか？ REST APIを使用するか、データベースを直接クエリしますか？
賢明なパフォーマンスとは何ですか？ REST APIを作成し、WebアプリでREST APIを使用してデータベースとのすべてのやり取りを行うORデータベースを直接（つまり、JDBC for Javaなどのデータベースをクエリするために言語が使用する一般的なオブジェクトを使用）？
RESTでそれを見る方法：
- コード内にオブジェクトを作成してRESTメソッドを呼び出す
- Httpメソッドを呼び出す
- REST API内のコードはデータベースに問い合わせます
- データベースはデータを返します
- REST APIコードはデータをJsonにパックし、クライアントに送信します
- クライアントはJson/XML応答を受信します
- コード内のオブジェクトへの応答のマッピング
一方、データベースを直接クエリする場合：
- データベースをクエリするクエリ文字列を使用してオブジェクトを作成します
- データベースはデータを返します
- コード内のオブジェクトへの応答のマッピング
REST APIの使用が遅くなるという意味ではないでしょうか？データベースのタイプ（SQLとNoSQL）に依存するかもしれません）？
複雑さを追加すると、コードの実行が遅くなります。 RESTサービスが必要ない場合、サービスを導入すると、システムの処理が増えるため、実行速度が低下します。
データベースを抽象化することは良い習慣です。速度が心配な場合は、リクエストを処理するためにデータベースを操作する必要がないように、メモリ内のデータのキャッシュを調べることができます。
パフォーマンスを最適化する前に、解決しようとしている問題と使用しているアーキテクチャを調べますが、データベースオプションが直接アクセスとRESTのどちらであるかを考えるのに苦労しています。
速度が気になる場合は、上記の理由により、Restサービスの速度が遅くなります。ただし、説明するタイプの速度が主な問題になることはめったになく、そうである場合は他の方法で対処できます。 時期尚早な最適化はすべての悪の根源です 。
相互運用性（モバイル、Web、B2B）が主な関心事であるかどうかを検討してください。RESTはテクノロジーにとらわれないため、非常に魅力的です。
データベース用にコーディングするとします。基になるデータストアを変更する場合はどうしますか。基礎となるストアに密接に結合されている場合、それはどのくらい難しいでしょうか？
本当の答えはそれは依存しますですが、うまくいけば、私はあなたに考えるいくつかのことを与えました！
この質問に答えるのが難しい場合。
正しい一般的な答えは次のとおりです。
RESTでそれを見る方法：
- コード内にオブジェクトを作成してRESTメソッドを呼び出す
- Httpメソッドを呼び出す
- REST API内のコードはデータベースに問い合わせます
- データベースが一部のデータを返します
- REST APIコードはデータをJsonにパックし、クライアントに送信します
- クライアントはJson/XML応答を受信します
- コード内のオブジェクトへの応答のマッピング
君の考えには間違いがある。
そして、この間違いは、RESTとその原理を完全には理解していないという事実に起因します。RESTは発明されなかった。もちろんそれは）JavascriptオブジェクトをHTTP経由で送信することです。HTTPを使用する主な利点は Caching を使用できることです。結果をキャッシュ可能にした場合の場合、DBへの要求は少なくなります。また、marshallingは含まれません。答えは直接お届けします。
これまでのところ、@ Kleesの答えは正しくない：
複雑さを追加すると、コードの実行が遅くなります。 RESTサービスが必要ない場合、サービスを導入すると、システムの処理が増えるため、実行速度が低下します。
キャッシュ可能な結果を処理する場合、アプリケーションへの影響はありません。既知の質問に対する既知の回答の提供は、リバースプロキシを介して行うことができます。
追加のサービス層を導入すると、複雑さとパフォーマンスのオーバーヘッドに常にコストがかかります。共有サービス層（REST API）など）を導入すると、共有キャッシュが原因でPERFORCEが向上する可能性のある特定の種類のアーキテクチャがあります。
同じデータベースに直接接続する複数のWebアプリまたは複数のデスクトップアプリがあるアーキテクチャを考えてみましょう。同じクエリを頻繁に実行する場合、クエリ結果を共有サービスにキャッシュするとパフォーマンスが向上する可能性があります。特に、何百ものデスクトップアプリが同じデータベースに直接アクセスし（Webアプリ経由ではない！）、同じクエリを実行すると言った場合、大幅な改善が見込めます。ただし、このアーキテクチャでも、共有サービスを導入する主な理由は、パフォーマンスではなくセキュリティとデータの抽象化であろう。
しかし、データベースに直接接続する単一のWebアプリがあるようです。その場合、追加のサービス層を導入するメリットはありません。キャッシュ、データベースの抽象化などは、同じアプリケーションのデータアクセス層で処理できます。
場合によります。
明らかに、コード内のレイヤーが多いほど、速度は遅くなります。しかし...直接的なエンドツーエンドのパフォーマンスがスケーラビリティほど重要ではない場合があります。 1人のユーザーがローカルPC上のデータベースにアクセスしている場合、高速に処理できます。同じPC上の同じDBにアクセスする1000人のユーザーがいる場合、それらすべてが不満を感じることになるでしょう。解決策は、DBを別のボックスに移動し、中央にレイヤーを追加することです。1人のユーザーの場合、パフォーマンスは遅くなりますが、1,000人がアクセスすると高速になります。 （それは単純な答えですが、原則として正しいです）。
セキュリティなど、DBを中間層レイヤーの背後に隠す理由は他にもあります。