REST APIをビジネスレイヤーとして使用できますか？
私はPHP Codeigniter [〜＃〜] mvc [〜＃〜]設計パターンを使用しています
そして私はある種の特定のビジネスプロセスを備えたこのプロジェクトを持っていました
私のアプリケーションでは、2つの既存のREST APIを扱います。
- グーグル
- トレロ
REST APIビジネスロジックレイヤー（BBL）として機能するように作成するというアイデアを思いつきました
次に、モデルに直接アクセスして、ビジネスルールを作成するために必要なデータをフェッチします。
RESTクライアントを使用してBLLと通信するコントローラー、 
それはパフォーマンスにとって悪いアプローチですか？
2レイヤーモデルの1つをデータアクセスレイヤー（DAL）として作成し、もう1つをビジネスロジックレイヤー（BLL）として作成する方が良いですか？
あなたのアプローチで私が目にする問題は、あなたがREST APIを1つのコンシューマー、コントローラーだけに構築していることです。それはやり過ぎです。1つのレイヤーからデータを渡すためだけにレイヤーを追加しないでください。もう1つは、意味がありません。追加の利益なしに自分で作品を作成することになります。
APIを便利にする（迅速な）方法の1つは、それがコントローラー（つまりアプリケーション）が必要とする唯一のエンドポイントである場合です。このことを考慮：
突然、あなたのREST APIには目的があり、それはさまざまなデータプロバイダーへの統一されたインターフェイスを提供することです。アプリケーションは、GoogleやTrello API、その他のAPIについて知る必要はありません。あなたが将来使用するかもしれないデータプロバイダー、それはあなたのREST APIについて知る必要があるだけです。
この設計は、多少便利ではありますが、アプリケーションが唯一のコンシューマーである場合は、やり過ぎです。 REST APIを構築する全体のポイントは、アプリケーションが共有できる公開インターフェースを公開することです。そして、ここでの鍵は公開です。REST APIは必須安全である必要があります。APIの認証と承認は単純なタスクではなく、1つのアプリケーションだけがAPIを使用するのであれば、なぜすべてのトラブルを経験するのでしょうか？もちろん、実験したくない場合を除きます。そうだとすれば、ぜひやってみてください。
いずれにしても、パフォーマンスは問題になりません。追加のレイヤーを追加するので、明らかにオーバーヘッドが発生しますが、そのオーバーヘッドが大きくなるかどうかは、実装に完全に依存します。 REST APIが単一のエンドポイントである場合、キャッシングが発生する場所も1つにすることをお勧めします。サーバー側のキャッシングだけでなく、REST APIを使用すると、ブラウザーのキャッシュが悪用されやすくなります。正しく取得すると、REST以外のアプローチと比較して、アプリケーションの全体的なパフォーマンスが向上する可能性があります。
tl; dr：（学んでいない限り）実際の目的を持たないものを構築しないでください。
あなたの図面に基づいて、Googleとのやり取り、結果の取得、アプリ用のフォーマット化を処理するコントローラーによって呼び出されるモデルがあるはずです。その後、それはコントローラーに送信され、準備が整います。つまり、Google固有の詳細はすべてそのモデルに含まれます。 trelloも同じです。そうすれば、消費するAPIをさらに追加する必要がある場合、すべてを適切に分離しておくことができます。
これは小さな詳細ですが、アプリの全体的な設計で覚えておいてください。APIサーバーからサーバーへの情報の送信/取得の遅延の可能性を考慮する必要があります。言い換えれば、Trelloサーバーが遅いかダウンしている場合にアプリが完全にハングアップしないことを確認してください。
Apisはセキュリティに配慮する必要がありますが、必ずしも「公開」である必要はありません。多くのAPIは企業間で公開されていないものです。
私はこの本のほとんどを読みました-その短い、まだ初期のリリース、そして十分な例はありません-しかし、それは非常に最新で、すべてのphpであり、著者はAPIについて積極的に作成し、教えています。 http://shop.oreilly.com/product/0636920028291.do
著者は彼女のブログにphp rest api関連の投稿があります。 http://www.lornajane.net/blog
そして、API投稿のコメントを必ず読んでください！真剣にそれはあなたに非常に貴重な視点を与えます。
あなたがグーグル「ハイパーメディア」とAPIを提案します。あなたはそれを使いたくないかもしれませんが、API作成のための他のいくつかのテクニックを示します。
私はプログラマーに加わったばかりです-できればこの質問に賛成票を投じます！ほとんどの企業は、APIを消費または公開するためのまったく新しいアプリケーションを作成することはできません。そのため、APIを既存のMVCフレームワークに統合するためのベストプラクティスを考え出します。これは非常に重要です。