REST APIをバックエンドから使用することも悪い選択ですか？
RESTフロントエンドコードのAPIを使用することは、望ましい一般的な方法です。
しかし、私はそれをバックエンドにも使用することが良い選択になるかどうか疑問に思っていました。
つまり、データベースからデータを取得する負担をすべてAPIに任せ、データベースに直接クエリを実行する代わりに、データベースにクエリを実行する必要があるときはいつでも、バックエンドの他の部分（主にビューとコントローラー）から呼び出します。
私が本当に心配していることの1つはフロントエンドとバックエンドの間でいくつかのコードを共有するであり、データの共通ソースとしてAPIを使用すると非常に便利です。
だから問題はこれを悪いアイデアにするいくつかの理由はありますか？
コンポーネントをデータベースから切り離す/直接データベース接続から離れることは、一般的なパターンです。アクセスをミドルウェア/データベースのフロントエンドコンポーネントに移動すると、セキュリティとモジュール性が向上し、SQL、ストアドプロシージャ、クライアント側のデータベースコードに「陥る」データの検証と解釈を実装する場所が提供されます。これに対して、そのミドルウェア/データ管理フロントエンドの開発、ランタイム、そして場合によっては経済的コストを比較検討する必要があります。しかし、多くのプロジェクトスケールポイントでは、データフロントエンドが適切な選択と見なされることがよくあります。
RESTful APIを使用して、バックエンドのデザインとコンポーネントを制御する場合、特にその一般的な形式（例： HTTPによって提供され、JSONでエンコードされます-他の代替手段（たとえば、直接ライブラリリンク、 プロトコルバッファー 、 Thrift 、さまざまな種類の [〜 ＃〜] esb [〜＃〜] 、その他のRPCメカニズム、...）すべてのAPI呼び出しに対して、テキストへのシリアライズ、サーブ、テキストからのデシリアライズサイクルを実行しません。 RESTは、いくつかの構成要素（たとえば、マルチステップトランザクション、ストリーミング、大きなバイナリオブジェクト、例外の発生、保証された配信など）が与えられていることを考えると、意味論的にアーム長の相互作用メカニズムとしても優れています。より単純に、きれいに、または他の形式の相互作用で直接処理されます。
RESTfulバックエンドを引き続き使用する必要があるいくつかの理由：シンプルさ、一貫性（すべてのクライアント、ローカルまたはリモート、1つのAPIのみを使用）、および市場投入までの時間（たとえば、別のAPI /相互作用スタイルを学ぶ必要がない）。これらは、RESTful APIを介して比較的直接的にデータベースを公開していることを前提としています。制御下でのコンポーネントの使用が厳密である場合、RESTはおそらく（セマンティックの豊富さまたは効率のいずれかにとって）最良の選択ではありません。
データアクセスをRESTful APIにすることの根本的な正当化は、データアクセスが他の環境と関係を持つことになると思います。
考えてみてください。通常、APIの能力は、それを消費できる膨大な量のさまざまな「クライアント」実装者です。それはあなたのケースで違いはないはずです。
言い換えれば、この同じデータアクセスの複数のコンシューマーと異なる呼び出し元が存在する場合、および/またはそれをスケールアウトする場合、それは理にかなっていると思います。
しかし、逆に、コンシューマーが1人で、このデータアクセスとロジックが非常に具体的に調整されているため、スケーリングされない場合、RESTful APIを介してビットを転送することで何が得られるかわかりません。
必ずしも。ミドルウェアはすべてを処理することはできません。私がこれを示すために常に取り上げる3つの例があります：バッチ処理、転送、およびAPIチェーンです。これらはすべて、元のリクエストの範囲内に留まることでメリットがありますが、アプリケーションでは、プロキシ/ APIゲートを経由していったん離れて戻ってくる必要があります。
I/OをAPIから抽象化してインターセプターに移動することにより、プリハンドラー/ポストハンドラーを使用して通信を引き渡し、1つのスレッドを使用してループを処理できます。
APIゲートからアプリケーションインスタンス、応答ツールへのI/Oフローは1つの定常フローであり、中断されません。
詳細については、API抽象化とAPIチェーンを参照してください（ http://www.slideshare.net/bobdobbes/api-abstraction-api-chaining ）
REST APIをバックエンドから使用することには、2つの利点があります。別のAPIを開発して文書化する必要がなく、2つではなく1つのバグセットしかありません。
2つの考えられる異論があります。バックエンドが既存のAPIに適合しないことを行う可能性があります（フロントエンドAPIが行うのとは反対の方向からデータを見る可能性があるため）。また、パフォーマンスの問題が発生する可能性があります。バックエンドがフロントエンドの10倍のデータベースを使用し、それがパフォーマンスにとって重要である場合、最も単純なAPIではなく最速のAPIが必要です。
したがって、バックエンドがデータベースをどのように使用するかを確認し、そこから決定します。バックエンドがREST API機能に満足しており、パフォーマンスの問題がない場合は、REST APIを使用してください。
良い答えとコメントがたくさん。私には、マイクロサービス指向のようです。問題は、データアクセスとそのデータをチャーンするバックエンドコードの間にレイヤーを挿入するオーバーヘッドがわずかにあることです。開発時間とサイクルに関するオーバーヘッド、およびコードパフォーマンスに関するオーバーヘッド。しかし、利点は、アプリケーションコンポーネントがより緩やかに結合されているため、複雑さを抑えてコードを拡張/変更できることです。 APIを介してデータにアクセスするすべての処理が行われる場合、APIをシームレスに処理させると、基盤となるデータモデルに必要な変更がすべて完了します。
逆に、コードのいくつかの部分が複数の場所のデータにアクセスしている場合は、さらに検討および実行してテストする必要があります。また、バックエンドコードがデータにアクセスする場所が複数ある場合、不整合が発生する傾向があります。